Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 May 95 11:27:41 MDT
From:      terry@cs.weber.edu (Terry Lambert)
To:        hsu@cs.hut.fi (Heikki Suonsivu)
Cc:        freebsd-current@freefall.cdrom.com
Subject:   Re: bin/407: Odd tset -I behaviour, termcap says xterm kb=^H
Message-ID:  <9505161727.AA19931@cs.weber.edu>
In-Reply-To: <199505160816.LAA14553@shadows.cs.hut.fi> from "Heikki Suonsivu" at May 16, 95 11:16:04 am

next in thread | previous in thread | raw e-mail | index | archive | help
>    Most X terminals interpret this as a request to send an ASCII Backspace
>    character (^H, 0x08) to the slave side of the PTY they are using.
> 
> The Tektronics X terminals here send ^? and have the key most people talk
> about as "Backspace" labelled with left-arrow.  Ditto for all workstations
> here, though they are mostly Suns or Linux PC's.

The Xterminals send no such thing.  They send an X keycode -- they don't
talk ASCII at all, they talk X.  It is your Xterm program that you are
running against your X terminal that is putting the ASCII value out based
on the keycode it gets in the XKeyPressEvent.

In other words, it is a configuration issue for your xterm.

Since the xterm stuffs its termcap into the environment for the child
program on the slave side of the pty (usually your shell), the issue is
making it provide the correct termcap 'le' capability to identify the
left arrow so that tset (which you should run) can set the tty erase
character correctly.

Alternately, you can change the keycode for the erase character on the
X terminal globally (or leave it as whatever it is), and then use xrdb
to intern an atom for the xterm TtyModes capability to match the xterm.

This should be done as part of running xdm on the terminal and causing
a login (see the xdm documentation), or as part of the user's .xinitrc
if the X server is started from a command line instead of from xdm by
init (see the xdm documentation).

Either way, any xterm program that runs against the X server is going
to prefer the interned atom (which it is your job as system administrator
to ensure matches the keycode on a per X terminal basis) to the user's
.Xdefaults value (which could be correct only for one terminal) or the
xterm defaults compiled into the program.

This would resolve the issue entirely for all xterms consuming the display
services of your X server, regardless of origin.

>    I would say that your console is configured incorrectly by default
>    to send and ASCII 0x7f (delete, ^?) instead of an ASCII backspace for
>    your key labelled "Backspace", and that the default tty modes for
> 
> I don't care about the damn labels, but the function of the keys.  I expect
> the big key above enter/return/whatever to erase the previously typed
> character, and thus it needs to send ^? unless ANSI has changed its mind (I
> have only seen a quote from the standard, though).

The conclusion "thus it needs to send ^?" is incorrect, and is based on
what you presume are the default tty modes for the terminal.

It would be more correct to say that the value that that key sends should
be encoded on a per terminal type basis in the /etc/termcap file as the
'le' capability, and the terminal type should be specified on the getty
line in the /etc/ttys file so that getty can do the correct thing by
initializing the correct erase character.

For logins not through getty (or through mgetty, which has not been
sufficiently BSDized), the users shell initialization is expected to
invoke "tset", which is expected to cause the 'le' capability to be
loaded as the tty erase character.

> I'm willing to pay for
> related standards from ANSI for FreeBSD group so that we can get rid of
> this confusion.  There are at least three standards related to ASCII, X3.4,
> X3.41 and X3.32, I don't know which one is the one which specifies the
> correct usage but I can pay them all, it should be less than $200 in total
> including shipping, probably less, $100-$150.  Which snail address I should
> order them to in case ANSI agrees to ship them directly even when order
> comes from abroad?

I believe the standard you want is X3.64, which covers key codes sent,
and escape sequences processed, by ANSI compliant terminals.  I believe
since the console software presumes to VTxxx series compliance that you
will want the 1977 version of this standard.  I'd send you a copy of mine,
but I'm reluctant to violate copyright.

ANSI standards *do not specify* key arrangement vs. ASCII code returned.

>    The Telnet and Rlogin arguments don't hold water here because the
>    erase character is a negotiated option.
> 
> rlogin doesn't negotiate this, just the terminal type (but rlogin
> "protocol" is high in brokeness scale anyway).  Telnet we don't use much as
> it keeps asking stupid passwords sent as cleartext over network.  rlogin
> will be replaced RSN by a better method :)

Negotiation of the terminal type is sufficient to provide an 'le' capability
to the tset program, which is expected to be run in your .login or .profile
depending on your shell choice.


					Regards,
					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9505161727.AA19931>