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 different terminals 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.
According to https://www.usenix.org/legacy/publications/library/proceedings/vhll/full_papers/korn.ksh.a:
The popular inline editing features (vi and emacs mode) of ksh were
created by software developers at Bell Laboratories; the vi line
editing mode by Pat Sullivan, and the emacs line editing mode by Mike
Veach. Each had independently modified the Bourne shell to add these
features, and both were in organizations that wanted to use ksh only if ksh
had their respective inline editor. Originally the idea of adding
command line editing to ksh was rejected in the hope that line editing would
move into the terminal driver. However, when it became clear that this
was not likely to happen soon, both line editing modes were integrated into
ksh and made optional so that they could be disabled on systems that provided
editing as part of the terminal interface.
So instead, they implemented both and an interface for users to choose between the two.
ksh was most probably the first in the early 80s (reusing code that had been written separately to add a vi mode and an emacs mode to the Bourne shell as seen above) followed by
tcsh initially only had
emacs key binding,
vi mode was added later) and later
zsh in the early 90s.
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
sh (the story has that Richard Stallman objected to POSIX specifying 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 unless
ksh also later added a
gmacs mode to accommodate users of Gosling
emacs that handled Ctrl+T differently.
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.