Discussion:
backspace ^H vs ^? -- linux vs terminfo
(too old to reply)
Lőrinczy Zsigmond
2016-01-28 15:18:30 UTC
Permalink
Hi, I know how old this question is, only I cannot find the answer.

Here's the problem as far as I understand:

1. ncurses/terminfo states that xterm.kbs=^H (aka \b)

2. linux distributors merrily override this,
and define kbs=\177 (aka ^?)

3. some other platforms (eg. AIX) are terminfo-compatible

4. when you connect via telnet/ssh from one platform to the other,
and press backspace, you might get visible characters ^? or ^H
instead of erasing the last character.

(Plus, telnet/ssh daemons tend to happily ignore terminfo,
but that can fixed from some .profile-script:
X=$(tput kbs) && stty erase "$X")

5. there are other terminal-types which could be used (konsole,
for example), but xterm is the favourite terminal-type of
some programs like vim (try Shift+Arrow, Ctrl+Arrow keys
with TERM=xterm and with TERM=konsole)

6. so it would be good to have a standardized terminal type,
which is xterm-based (it's name is xterm-*), and behaves the
same way on every platform (that's what we call 'standard')
it could be either 'xterm-linux' (kbs=\177) or 'xterm-nonlinux'
(kbs=\b') just be the same everywhere
Kaz Kylheku
2016-01-28 18:04:33 UTC
Permalink
Post by Lőrinczy Zsigmond
Hi, I know how old this question is, only I cannot find the answer.
Which character comes out of the terminal or terminal emulator
when you hit Backspace is, first and foremost, a matter of that terminal
emulator and its specific internal configuration.

For instance, if you're sitting behind a Windows box using PuTTY, you
can choose whether your backspace generates character 8 or 127. This is
in the PuTTY Configuation dialog under Keyboard. Notice how this
setting is completely external to the host you are connecting to;
it just determines what should happen when the running putty.exe
receives a Backspace key event in its window: what character should
it transmit to the host.

On the host side, things have to match your chosen Backspace key for
it to work right.

This is not one single thing; it depends on the software.

- Firstly, the remote kernel's tty driver has to be informed of the
correct backspace key that your terminal emulator is generating.
You can do this with the "stty erase <arg>" command.
This is so that backspacing works when you are interacting with
the kernel's "canonical input processing mode": a crude form of
line input which is used for interacting with programs that do not
support any sort of visual editing. For instance,
when you do "cat > file" (then type content, followed by Ctrl-D on
a blank line), the crude line editing you can do, including
backspace, is provided by the TTY driver in the kernel, and
your backspace character is matched to the character erase action
via the configuration.

- Secondly, in some visual programs, it won't matter which backspace
you configure, because they are smart enough to do this:

switch (input_character) {
...
case 8: case 127: /* A basta! Support both backspaces! */
erase_char(my_context);
...
}

- Some visual programs will support only one backspace character,
and they obtain its identity from the TTY driver. In other words,
whatever you configured using "stty erase <arg>" in the shell.
So it is important to inform the TTY driver of the correct character
not only for the sake of canonical input processing mode.

One program which is like this is GNU Bash. Its visual editing mode
recognizes only one erase character, and it corresponds with the
one in the TTY.

This makes it easier to fix th eproblem in Bash, because if the
setting is wrong, then your correct backspace character appears
literally. So in Bash you can do this:

bash$ stty erase <type Backspace here>

If your Backspace character appears literally, then you know it is
wrongly configured. Just hit Enter, and now it is right!

If your Backspace backspaces, then don't bother.

- Visual programs which rely on terminfo are ... screwed. Don't use
them, if possible. The idea of backspace being configured in terminfo
is quite silly, given that this is a setting that can be changed in
all the popular terminals. The purpose of terminfo is to describe fixed
properties of a terminal. In "xterm", the backspace can be flipped
between BS and DEL at run-time just like in PuTTY. (Try it: fire up an
xterm and then Ctrl-Left-Click in the window; the toggle is in the
pop-up menu).

If a program insists that the terminal you are using (according to the
indentity in the TERM variable, through terminfo) must be generating a
particular backspace, you either just have to reprogram the backspace
key locally in your terminal to satsify that program, or else find a
value for TERM which points sto a compatible terminal whose terminfo
entry has the other backspace key hard-coded.
Post by Lőrinczy Zsigmond
6. so it would be good to have a standardized terminal type,
which is xterm-based (it's name is xterm-*), and behaves the
same way on every platform (that's what we call 'standard')
it could be either 'xterm-linux' (kbs=\177) or 'xterm-nonlinux'
(kbs=\b') just be the same everywhere
That better be called "xterm-del" and "xterm-bs", instead of tying
it to Linux.

This is a poor solution; programs should just friggin' accept both keys,
or else use the one indicated in the "struct termios" structure pulled
from the tty device via "tcgetattr(STDIN_FILENO, ...)", not terminfo.
Lőrinczy Zsigmond
2016-01-29 05:36:56 UTC
Permalink
Hi, thank you for your valuable input;
also your answer made me bring up some more points:

1. putty made a clever move: invented its own terminal types
(putty and putty-256color), which are (should be)
platform-independent. Also putty doesn't really emulate xterm,
so it is a good idea to use TERM=putty instead of TERM=xterm

Otherwise some programs prefer TERM=xterm-*; for example try
shift+arrows in vim.

2. I don't wish to fix a few programs, I wish to go form Windows to
linux then from linux to AIX, and having BackSpace work in every
context (including ksh, dash, less, more, and more)

3. Incidentally, I am also the maintainer of a terminal emulator
program; it has a config-file that defines (on terminal-type bases)
what to send when the user presses BS
So right now it has two xterm's: xterm-terminfo-compatible(kbs=^H)
and xterm-linux-compatible(kbs=^?).
It's working in simpler cases, but and doesn't work in the
Windows -> linux -> AIX situation (see point 2)
Scott Dorsey
2016-01-29 15:50:54 UTC
Permalink
Post by Lőrinczy Zsigmond
Hi, thank you for your valuable input;
1. putty made a clever move: invented its own terminal types
(putty and putty-256color), which are (should be)
platform-independent. Also putty doesn't really emulate xterm,
so it is a good idea to use TERM=putty instead of TERM=xterm
Putty predates xterm, I believe. It closely follows the ansi standard.
Really, by the time xterm came out in the early nineties, all of the
terminal standards had been set many years ago.
Post by Lőrinczy Zsigmond
2. I don't wish to fix a few programs, I wish to go form Windows to
linux then from linux to AIX, and having BackSpace work in every
context (including ksh, dash, less, more, and more)
That's why stty exists.
Post by Lőrinczy Zsigmond
3. Incidentally, I am also the maintainer of a terminal emulator
program; it has a config-file that defines (on terminal-type bases)
what to send when the user presses BS
So right now it has two xterm's: xterm-terminfo-compatible(kbs=^H)
and xterm-linux-compatible(kbs=^?).
It's working in simpler cases, but and doesn't work in the
Windows -> linux -> AIX situation (see point 2)
Well, fix it then.

People have been dealing with the bs vs. del and the cr vs. crlf issues
since the days of teletypes. It's annoying but it's been entrenched for
many decades and so just about everything out there deals with it.
Use stty, that's what it's for.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Dan Cross
2016-01-29 16:31:46 UTC
Permalink
Post by Scott Dorsey
Post by Lőrinczy Zsigmond
Hi, thank you for your valuable input;
1. putty made a clever move: invented its own terminal types
(putty and putty-256color), which are (should be)
platform-independent. Also putty doesn't really emulate xterm,
so it is a good idea to use TERM=putty instead of TERM=xterm
Putty predates xterm, I believe. It closely follows the ansi standard.
Really, by the time xterm came out in the early nineties, all of the
terminal standards had been set many years ago.
[snip]
This is incorrect. Xterm was written in 1984. PuTTY is ca. 1998; thus
xterm is about 15 years older than PuTTY. Xterm was written in a time
when actual serial terminals were still common, and bitmapped graphics
displays were still somewhat novel.

- Dan C.
Kaz Kylheku
2016-01-29 17:48:49 UTC
Permalink
Post by Scott Dorsey
Post by Lőrinczy Zsigmond
Hi, thank you for your valuable input;
1. putty made a clever move: invented its own terminal types
(putty and putty-256color), which are (should be)
platform-independent. Also putty doesn't really emulate xterm,
so it is a good idea to use TERM=putty instead of TERM=xterm
Putty predates xterm, I believe.
Are you feeling OK?
Post by Scott Dorsey
Really, by the time xterm came out in the early nineties, all of the
terminal standards had been set many years ago.
xterm came with the XWindow system, which released in 1984.

"Simon Tatham (born 3 May 1977) is a British programmer known primarily
for creating and maintaining PuTTY.. " [Wikipedia]

So, he was seven years old.

PuTTY started in 1998; it wasn't widely known until the 2000's.
Scott Dorsey
2016-01-29 18:52:48 UTC
Permalink
Post by Kaz Kylheku
Post by Scott Dorsey
Post by Lőrinczy Zsigmond
Hi, thank you for your valuable input;
1. putty made a clever move: invented its own terminal types
(putty and putty-256color), which are (should be)
platform-independent. Also putty doesn't really emulate xterm,
so it is a good idea to use TERM=putty instead of TERM=xterm
Putty predates xterm, I believe.
Are you feeling OK?
Post by Scott Dorsey
Really, by the time xterm came out in the early nineties, all of the
terminal standards had been set many years ago.
xterm came with the XWindow system, which released in 1984.
Is X really that old? I don't think I ever saw it until well after 1990.
I think the first time I saw it was an experimental install replacing SunView
with it.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Scott Dorsey
2016-01-28 21:20:24 UTC
Permalink
Post by Lőrinczy Zsigmond
Hi, I know how old this question is, only I cannot find the answer.
1. ncurses/terminfo states that xterm.kbs=^H (aka \b)
2. linux distributors merrily override this,
and define kbs=\177 (aka ^?)
3. some other platforms (eg. AIX) are terminfo-compatible
4. when you connect via telnet/ssh from one platform to the other,
and press backspace, you might get visible characters ^? or ^H
instead of erasing the last character.
(Plus, telnet/ssh daemons tend to happily ignore terminfo,
X=$(tput kbs) && stty erase "$X")
5. there are other terminal-types which could be used (konsole,
for example), but xterm is the favourite terminal-type of
some programs like vim (try Shift+Arrow, Ctrl+Arrow keys
with TERM=xterm and with TERM=konsole)
6. so it would be good to have a standardized terminal type,
which is xterm-based (it's name is xterm-*), and behaves the
same way on every platform (that's what we call 'standard')
it could be either 'xterm-linux' (kbs=\177) or 'xterm-nonlinux'
(kbs=\b') just be the same everywhere
So what is the problem? You want to use either one, you set them with
stty and you don't worry about it.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Kaz Kylheku
2016-01-28 21:44:58 UTC
Permalink
Post by Scott Dorsey
So what is the problem? You want to use either one, you set them with
stty and you don't worry about it.
That works for me; I am not aware of any programs that I use which
insist on recognizing only the backspace character that is indicated in
a terminfo entry, ignoring the one from the TTY.
Scott Dorsey
2016-01-29 00:42:17 UTC
Permalink
Post by Kaz Kylheku
Post by Scott Dorsey
So what is the problem? You want to use either one, you set them with
stty and you don't worry about it.
That works for me; I am not aware of any programs that I use which
insist on recognizing only the backspace character that is indicated in
a terminfo entry, ignoring the one from the TTY.
Regular vi is bad about this. I don't know if any of the vi clones are
better or not.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Dan Cross
2016-01-29 15:02:56 UTC
Permalink
Post by Scott Dorsey
So what is the problem? You want to use either one, you set them with
stty and you don't worry about it.
Indeed. A few years ago, I went through the process of trying to
rationalize all of this backspace nonsense across the various terminal
emulators I use to access machines of different types. I wanted to
standardize and use BS everywhere, but it was a failure; I finally
gave up and just put "stty erase '^?'" in my shell profiles. Life is
too short; there are better things to worry about.

I do find it amusing that we're still fighting infrastructure built
for handling the gratuitous differences between systems that haven't
mattered for two decades, that in turn were built to handle gratuitous
differences between hardware that hasn't mattered for twice that
amount of time.

- Dan C.
oldunixguy
2016-01-30 05:05:42 UTC
Permalink
Post by Lőrinczy Zsigmond
Hi, I know how old this question is, only I cannot find the answer.
1. ncurses/terminfo states that xterm.kbs=^H (aka \b)
2. linux distributors merrily override this,
and define kbs=\177 (aka ^?)
3. some other platforms (eg. AIX) are terminfo-compatible
4. when you connect via telnet/ssh from one platform to the other,
and press backspace, you might get visible characters ^? or ^H
instead of erasing the last character.
(Plus, telnet/ssh daemons tend to happily ignore terminfo,
X=$(tput kbs) && stty erase "$X")
5. there are other terminal-types which could be used (konsole,
for example), but xterm is the favourite terminal-type of
some programs like vim (try Shift+Arrow, Ctrl+Arrow keys
with TERM=xterm and with TERM=konsole)
6. so it would be good to have a standardized terminal type,
which is xterm-based (it's name is xterm-*), and behaves the
same way on every platform (that's what we call 'standard')
it could be either 'xterm-linux' (kbs=\177) or 'xterm-nonlinux'
(kbs=\b') just be the same everywhere
Where can I find the terminal entry for "putty"? On various linux systems I have there is no such entry and the xterm entry just doesnt work with the putty client, especially with the man command- the output is messed up missing text and highlighting is gone.
thanks
oldunixguy
PS. I used X and xterms back in the mid 1980s!
Lőrinczy Zsigmond
2016-01-30 07:33:26 UTC
Permalink
Post by oldunixguy
Where can I find the terminal entry for "putty"?
On various linux systems I have there is no such entry
and the xterm entry just doesnt work with the putty client,
especially with the man command-
the output is messed up missing text and highlighting is gone.
terminfo is part of ncurses
Copyright © 1996-2013,2014 by Thomas E. Dickey
http://invisible-island.net/ncurses/ncurses.html
Scott Dorsey
2016-01-30 15:45:51 UTC
Permalink
Where can I find the terminal entry for "putty"? On various linux systems I=
have there is no such entry and the xterm entry just doesnt work with the =
putty client, especially with the man command- the output is messed up miss=
ing text and highlighting is gone.
thanks
Putty emulates an ansi terminal, so you might start with the ansi termtype.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Lőrinczy Zsigmond
2016-01-31 13:15:41 UTC
Permalink
Post by Scott Dorsey
Putty emulates an ansi terminal, so you might start with the ansi termtype.
Well, command 'infocmp -1 putty ansi' suggests otherwise
Scott Dorsey
2016-01-31 16:24:00 UTC
Permalink
Post by Lőrinczy Zsigmond
Post by Scott Dorsey
Putty emulates an ansi terminal, so you might start with the ansi termtype.
Well, command 'infocmp -1 putty ansi' suggests otherwise
Doing that, it sure looks like the 'putty' here on NetBSD is a superset of ansi.
Mind you, xterm is also a superset of ansi, but a very different one.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Loading...