Re: Emacs in a terminal via qrsh on Sun Grid Engine - text rendering

[Bob Proulx <bob@proulx.com>]

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