From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bob Proulx Newsgroups: gmane.emacs.help Subject: Re: Emacs in a terminal via qrsh on Sun Grid Engine - text rendering Date: Sat, 17 Oct 2015 14:01:15 -0600 Message-ID: <20151017133104720684413@bob.proulx.com> References: <1444752092.2716.27.camel@PSY0001622> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1445112106 18625 80.91.229.3 (17 Oct 2015 20:01:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 20:01:46 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Oct 17 22:01:35 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZnXfY-0005TB-N4 for geh-help-gnu-emacs@m.gmane.org; Sat, 17 Oct 2015 22:01:32 +0200 Original-Received: from localhost ([::1]:59616 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnXfX-0000za-SF for geh-help-gnu-emacs@m.gmane.org; Sat, 17 Oct 2015 16:01:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnXfN-0000zV-BB for help-gnu-emacs@gnu.org; Sat, 17 Oct 2015 16:01:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnXfJ-0002je-AK for help-gnu-emacs@gnu.org; Sat, 17 Oct 2015 16:01:21 -0400 Original-Received: from joseki.proulx.com ([216.17.153.58]:51082) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnXfI-0002j2-Ts for help-gnu-emacs@gnu.org; Sat, 17 Oct 2015 16:01:17 -0400 Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 5A0D12198B for ; Sat, 17 Oct 2015 14:01:15 -0600 (MDT) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id 39A232DC48; Sat, 17 Oct 2015 14:01:15 -0600 (MDT) Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <1444752092.2716.27.camel@PSY0001622> User-Agent: Mutt/1.5.24 (2015-08-30) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 216.17.153.58 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:107721 Archived-At: Seb James wrote: > The problem is incorrectly rendered text, such as might be seen if the > terminal settings were incorrectly matched between the client terminal > and the user's environment on the server. The text can be corrected with > a C-l, as reported by other users who have had mis-rendered text > problems. The sort of misrendering is very similar to that reported > here, although the cause is different there: > > http://emacs.stackexchange.com/questions/9512/why-does-the-buffer-get-garbled Garbled text on a text terminal today using TCP/IP connections I think is mostly likely caused by a mismatched termcap / terminfo database. Perhaps even an incorrect and buggy termcap / terminfo database. The side running emacs thinks the terminal is one way and the terminal emulator thinks it is another way. The garbled output tends to appear when incremental updates are applied to the terminal. The cursor is told to move to an x,y location on the screen. Something is diddled there. Move. Diddle. Move diddle. But the screen gets garbled when the terminal does not actually do what the update intended. This gets fixed with a C-l because C-l was designed in the days of modem noise which would cause the screen to be modified in ways unknown to the program. It is designed to clean up after this type of problem. It will clear the screen to get to a known empty state and paint top to bottom a clean display output of what should be there. That cleans up all of the garbled output. > Our HPC system runs Sun's Grid Engine to manage all the worker nodes. > Here is the workflow: I ssh on to the head node, then to do any work, I > am required to request a session on one of the worker nodes. To do this > I use the Sun Grid Engine (SGE) binary "qrsh" which opens a remote shell > on a host of SGE's choosing. If I now emacs -nw somefile.cpp, I quicly > see mis-rendering of the text. After you have grabbed a node can you then ssh directly to that node for a test? After grabbing a node with qrsh in parallel with it ssh into the node using a normal ssh login outside of SGE. Does the problem exist that way too? If the problem does not exist then the issue is something in the sge qrsh environment. Having a working environment should allow you to do A-B comparisons between one and the other and quickly figure out what is different. If the problem exists with the direct connection then the issue is not related to SGE qrsh and is simply an environment issue. (I still suspect terminfo / termcap problems.) > Recently emacs became available on the head node, and I see no such > problem when using emacs in the terminal on this system. Therefore, the > problem seems to occur only when using qrsh to get to a worker node. > > I have studied my TERM environment variable. On my Linux client system > it is xterm-256color, on the head node it is also xterm-256color and on > the worker node the same. I would be inclined to examine closely any differences between versions on head and versions in the cluster. Specifically terminfo down the /usr/share/terminfo tree. I am really suspecting that terminfo is different between the systems. > I've looked at stty output, here are the changed values on the worker > node: > > [me@hpcnode03 ~]$ stty > speed 38400 baud; line = 0; > -brkint -imaxbel > -onlcr > > And on the head node: > > [me@myhpc-login1 ~]$ stty > speed 38400 baud; line = 0; > eol = M-^?; eol2 = M-^?; > -brkint ixany This leads me to think that the software versions are not identical between the head node and the rest of the cluster. You can make the tty settings identical manually by cutting and pasting the output from one into the other. Dump it from one: $ stty -g 4500:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 And past it into the other. $ stty 4500:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 That will make them identical among compatible systems. > I encounter the problem regardless of which client terminal I use to > connect to the HPC system (via ssh on Debian or Ubuntu or putty on > Windows and I think I tried ssh from Mac, too). > > Does anyone have any suggestions about how to debug this? Of course, it > may be a bug in Sun Grid Engine's qrsh program. Does anyone else on the > list use emacs via Sun Grid Engine? Seen this issue? It has been several years since I have used SGE. But I am familiar with it and some other queue systems. Do you have any TERMCAP or TERMINFO variables set in your environment? https://en.wikipedia.org/wiki/Termcap#Environment_variables env | grep TERM An environment variable would (could if set) override the system definition. This could be a cause of a problem. It might also allow you to easily override a system if the system were incorrect. I have often over the years run into incorrect terminfo databases. Bob