3

As I understand it, when typing characters in a terminal emulator they appear because they are "echoed". We imagine that the terminal is a separate device communicating with the computer via a two-way channel, and each key typed doesn't update the screen immediately, but appears when it is sent back from the computer.

My question is how it is possible for the backspace key, or whatever key is set to "erase" with stty, to appear to erase a character on the screen. If in an xterm I do

$ stty erase x
$ cat -
aaaaaaaaaax

the last x I type appears to erase the last a. However if this were a real terminal, separate from the computer, it wouldn't have any way of knowing what the stty erase character was. The only way I would expect to get this behaviour would be if the erase character was ^H and it was echoed, and the terminal interpreted this as a special control character telling it to erase the character before the cursor.

Is this a peculiarity of terminal emulators, where they "cheat" and look up what the stty erase character is?

1
  • Even in physical terminals, there's something called the "line discipline". It's the line discipline which would handle this.
    – muru
    Nov 17, 2014 at 18:21

1 Answer 1

Reset to default
2

The terminal emulator sends the x character, and the terminal driver sees that this has been configured as the erase character. So instead of echoing it back to the emulator, it sends the appropriate sequence to erase the previous character (e.g. backspace-space-backspace).

Even when the erase character is set to Backspace, simply echoing it wouldn't actually erase what was typed. When a BS character is sent to a terminal, it just moves the cursor one character to the left, it doesn't clear it. So the terminal driver would still have to send an extra space-backspace to clear it and leave the cursor at that location.

6
  • This is true for the linux virtual console driver since it is emulating a real terminal on a VGA display, but is not true of real terminals, which is what the question was about
    – psusi
    Nov 17, 2014 at 21:28
  • I'm pretty sure it's true of all terminals, it's part of the "cooked" line discipline.
    – Barmar
    Nov 17, 2014 at 21:33
  • That is implemented in the real terminal, not the kernel driver. With a real hardware terminal, it handles local line buffering, echoing, and backspace, and only sends the finished line down the wire when you press enter.
    – psusi
    Nov 17, 2014 at 21:38
  • While hardware terminals can be put into half-duplex mode so they do their own echoing, I think this is rarely used on Unix, because it doesn't allow input editing. It was used in the very early days -- the erase character was #, and it didn't erase anything in real time. But hardware terminals are practically unknown these days, almost all terminals are emulated, either in the console driver, window applications like xterm, or network applications like PuTTY.
    – Barmar
    Nov 17, 2014 at 21:43
  • I don't know if Unix ever did this, but on some operating systems, if you were using a printing terminal (e.g. DecWriter) and entered the erase key, it would back up and overstrike the character with something to indicate that it had been erased, then move forward over the erased input.
    – Barmar
    Nov 17, 2014 at 21:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .