[Info-vax] VMS terminal support

[Johnny Billquist]

On 2012-08-01 14:53, John E. Malmberg wrote:
> On 8/1/2012 5:18 AM, Johnny Billquist wrote:
>>
>> My point was that there is no response "seven bit". And believe me, I've
>> read the manuals backwards and forwards plenty of times.
>> I was curious on how people expected VMS to be able to set eightbit,
>> based on the information in DA1. Maybe something clever that I had
>> missed, but based on your responses, as well as the fact that VMS do not
>> set eightbit even if I have all the capabilities set correctly when I
>> test seems to prove that VMS does indeed not do this, as it can't.
>
> VMS only seems to be able designed to detect a specific set of VT series
> terminals that were sold by them or the company that now sells them.  In
> some cases it can get the geometry of the terminal, in others it can not.

Well, yes and no. VMS does not detect specific terminals, but only uses 
the somewhat generic responses from the DA1 escape sequence response. 
Geometry is basically guessed (well, pretty much assumed) to be 24x80, 
since almost all text terminals have that geometry.

> SSH passes a terminal identification string and the geometry, and maybe
> some other attributes to the end system.

It does, when the receiving system can understand that. However, that 
does not change that the actual terminal emulation you are running, in 
which you are then running ssh, also might respond to DA1. And I suspect 
that VMS looks more at that than what terminal string might be passed in 
the ssh protocol.

> Putty lies by default and tells the target system it is an xterm, even
> though by default it uses a reversed foreground and background.

VMS does not use that, as far as I know. VMS systems usually do a set 
term/inquire, which requests an identification from the terminal. The 
responses to this are not strings in the format you might be thinking.

> This lie means that the default color output on Linux can be a bit
> unreadable on Putty.

It is not necessarily lying. However, the whole thing is rather more 
complicated, and people often do not understand how things actually work 
together.

"xterm" does not even imply that color is possible, or how it is 
controlled. Unix traditionally have used the TERM variable to figure out 
the capabilities of the terminal, and there have never been a reliable 
way of automatically set the TERM variable correctly, nor are there any 
absolutely canonical list of names to use for the TERM value to indicate 
what terminal, and what capabilities you have. So, what terminal name 
should putty report, and what would that mean on the host? Pretty much 
impossible to tell, since there are no standards.
Unless I remember wrong, you can set what string putty should report as 
the terminal name, and you should set it to whatever you want, which 
gives the correct result on your host.
"xterm" is a pretty well accepted standard string, which implies a bunch 
of (more or less) accepted capabilities. Color is *not* among them.

>> If someone else can show VMS doing more, and even better, under which
>> circumstances, I'm curious to look at how it is done. The contents of
>> DA1 does not provide enough information, with the possible exception
>> that if you get a CSI as the eight bit character, that is a pretty good
>> indication that maybe eightbit should be set. (That bit of information
>> is, by the way, what RSX use to set EBC, which is actually exactly how
>> much it really tells.)
>
> Unfortunately it does not, so creating an algorithm to do so is up to
> someone else.

Right.

> The only reliable way that I can see to get the current terminal
> geometry is to move the cursor to various locations and then read it
> back.  And with "linked" screens active, even that can return false
> information.  That is also something needed to detect broken wrap.

Yes.

> And there are a number of terminal properties that an application would
> be interested in that do not seem to be supported by the
> terminfo/termcap database or ncurses.

terminfo/termcap and (n)curses are broken in their own way.

> Set term/inquire has some unfortunate side effects, such as sometimes
> setting the terminal geometry back to 24 * 80, depending on what it finds.

That is because VMS tries to be clever. It's not inherent in DA1.

> The Curses library in VMS is broken.  It does not matter what terminal
> type you tell it to return values for, it always returns the values for
> a VT100.  So even changing the terminal settings will not affect a C
> program that uses it.

Fun. I've never looked at the curses library under VMS.

> In the GNV sourceforge CVS directory for the VMS (gnu_vms subtree)
> specific changes to BASH-4.2 is a replacement curses implementation that
> actually reads the VMS terminal database and has an alias for xterm, and
> possibly some other models.
>
> I did what I could, but many of the termcap/terminfo settings are not
> documented at all.
>
> Linux does not seem to even attempt to auto-detect a terminal type.

No Unix system do. The closest I've seen is tset, which tries to do 
something similar to what VMS does. But it only exist on some Unix 
systems, and it's definitely something you have to invoke on your own, 
and because of other inherent weirdness in Unix, it is not uncomplicated...

	Johnny