GNOME Bugzilla – Bug 398401
gnome-terminal is not 100% VT compatible
Last modified: 2018-03-27 17:45:00 UTC
Please describe the problem: gnome-terminal doesn't fully work with VMS systems that expect a VT compatible terminal. xterm however works. Steps to reproduce: Connect to a VMS system, right at login the quota information is misformatted. TPU and NOTES also break. MONITOR works fine. Actual results: Raw ANSI escapes are shown, or inserted into edited files... Expected results: Does this happen every time? y Other information: A publicly accesible VMS system is {gein,manson}.vistech.net (ssh or telnet) (http://deathrow.vistech.net)
Moving to vte... It would really help to know exactly what control sequences are not working and, most importantly, what are they supposed to do.
From connecting to gein.vistech.net I can see at first view at least 2 things: * vte is mishandling default arguments to control sequences (cf. bug 400072) * Our terminal identification string is currently "62;9" which means "vt2x0 with national characters"; xterm, by default, uses "1;2" which means "vt100 with AVO". If I change vte to send "1;2" things get a bit better (there is no reason to try to pretend we have better capabilities than xterm, I guess). In any case, if you run ‘xterm -ti 220’ so that xterm identifies itself as a vt220, then its DECID becomes "62;1;2;6;9;15;22" and telneting to gein.vistech.net shows similar issues as vte when running NOTES. We are using "62;9" since we closed bug 130671. I am quite sure xterm did not use to default to reponding "1;2". I cannot tell from its changelogs though. :/
<<ESC [ 62 " p>> is also not matched.
Created attachment 82181 [details] [review] Use the default xterm DECID This patch makes vte respond with the same DECID xterm uses by default (you can change it using resources) when asked for it. (and removes a literal ESC character from the source, which is weird) This has the effect that the VMS at gein.vistech.net sees that we are not a VT220 and does not send us control sequences we can't parse. Not everything works, anyways...
Perhaps we should update the comment at the same time ;)
Should this go in?
*** Bug 344258 has been marked as a duplicate of this bug. ***
Closing this bug now; there've been many many changes since this was opened and it's unclear if any issues still apply. If you find a problem with vttest on vte git master please report new bug(s, one per issue). Make sure you use vttest from https://gitlab.gnome.org/chpe/vttest .