From owner-freebsd-current Wed May 17 14:45:52 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA15253 for current-outgoing; Wed, 17 May 1995 14:45:52 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA15247 for ; Wed, 17 May 1995 14:45:48 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA19931; Tue, 16 May 95 11:27:41 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9505161727.AA19931@cs.weber.edu> Subject: Re: bin/407: Odd tset -I behaviour, termcap says xterm kb=^H To: hsu@cs.hut.fi (Heikki Suonsivu) Date: Tue, 16 May 95 11:27:41 MDT Cc: freebsd-current@freefall.cdrom.com In-Reply-To: <199505160816.LAA14553@shadows.cs.hut.fi> from "Heikki Suonsivu" at May 16, 95 11:16:04 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > 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.