You'll notice that when you run
cat at a shell prompt on a terminal,
cat being supposed to write to stdout what it reads from stdin, and press a, you see a
a echoed back by the terminal driver, but
cat doesn't write that
a (you see only one
a, the one echoed by the terminal driver).
However, if you type a Backspace b Enter, you don't see
b and newline).
That is because the terminal driver (we're talking software in the kernel, not in the terminal emulator like
xterm) implements a very basic line editor when in canonical mode. The terminal driver can be configured using
ioctl() system calls like when using the
stty command. For instance, to leave the canonical mode, you can do
stty -icanon. If you do:
stty -icanon; cat
Then, you'll see both the
echo (which you could have disabled with
stty -echo) and the
cat output at the same time.
That editor is a line editor. That is, it is for the user to edit one line of text until it's sent to the application reading the terminal device upon pressing Enter.
The editing capabilities of that editor are very limited. In most implementations, there are only 4 editing keys (actually characters) also configurable with
- erase (
^? usually): erase the previous character
- kill (
^U usually): empty (kill) the line entered so far
- werase (
^W): erase the previous word
- lnext (
^V): enter the next character literally (cancel the special meaning of all of the above)
Back in the old days, it was thought that that terminal driver line editor would be extended with fancier capabilities. That is why none of the early shells has any command line editing capabilities (you'd get the same line editing capabilities at the shell prompt than when running
cat like we did above).
However, that really never happened, maybe part of the reason being the mess with the terminal drivers not sending the same characters upon some key presses which made it evident that that should not be implemented in kernel space.
So some shells started dropping the canonical mode of the terminal driver and implementing their own line editor. At the time,
vi were the most popular visual text editors with completely different key binding and operation mode. In
vi, you have one mode for entering text, and one for editing. In
emacs, you're always in entering text mode, but editing is done by pressing key combinations (like
^b to move the character backward).
There was no point for shells at the time to come up with their own different key binding. That would have caused frustration for people to have to learn a different one. However, choosing one (
vi) style over the other would have been a sure way to alienate the users of the other editor.
So instead, they implemented both and an interface for users to choose between the two. I think
tcsh was the first, then
ksh and later
You switch between the two modes in
set -o vi or
set -o emacs, and with
bindkey -e or
bindkey -v in
POSIX actually specifies the
vi mode and not the
emacs mode for
The default mode for
bash, the public domain variants of
ksh (pdksh, mksh, oksh),
zsh is the emacs mode (though with
vi if your
vi), while in the AT&T
ksh, it's the dumb mode (and you need to issue a
set -o vi or
set -o emacs to get a line editor (or start with
ksh -o emacs...)).
Now the handling of
emacs or in
tcsh emacs mode probably predates the
werase character in the terminal line editor, so we can't really blame them for that and my statement about "departing..." may be seen as misleading. It's just that I find it irritating when things like
info behave differently from everything else when you type Ctrl-W. You can imagine I found it a lot more irritating when some applications started to close their window when you typed Ctrl-W.