> Line editing...a backspace key is often useful. This could of course be implemented by the applications themselves, but in accordance with the UNIX design philosophy, applications should be kept as simple as possible. So as a convenience, the operating system provides an editing buffer
Actually this is backwards.
Line discipline is a historical artifact. Typically mainframes had IO front ends (AKA channel controllers) than managed IO so that the CPU (which BTW was what was charged for) could be kept busy and not wait around for users (by contrast CTSS, ITS and later machines like the Alto expressed an alternative, radical idea which was that the computer was there to support the user). Basically once a line was ready it was submitted by pressing the enter key and then its process was unblocked and processed the data. (Nowadays we just queue an event on the main thread...essentially the same thing!).
Likewise, a number of early network protocols like X.25 would charge per "line" (more about that later).
Unix was originally written for the PDP-7 (& later 11) which were minicomputers that didn't have channel controllers (in fact the earliest arpanet interfaces that weren't IMPS were PDP-11s acting as networking channel controllers for PDP-10 mainframes). Since IO was done by the kernel, you didn't want to to an expensive context switch for the common case of just reading a character and putting it into an input buffer.
So despite the comment quoted above, the true Unix model would have been for the kernel to have been agnostic and for each program to decide how it wanted to handle character input. But that would have been too expensive, so a more pragmatic approach prevailed.
By the way there are all sorts of other fossils in the TTY system. Multics used # to delete a character and @ to rub out the whole line -- a legacy of printing characters that persisted into Unix for years ###### decades. This seems weird today, but originally Multics (and later Unix) didn't have traditional line disciplines, or even control characters, much less select(). So it was handy to be able to essentially do immediate mode editing right in the input buffer.
Another fossil is that vi is just a visual mode grafted onto ed (clone of Multics qed IIRC), which was an editor with commands based on line-at-a-time IO.
ITS got proper IO virtualization first (and the predecessor to select, and extended it to the network with SUPDUP, later also implemented by Multics and eventually Unix, which made using Emacs possible) and actually had a more general version of select() before Unix was written, but at the time it was considered exotic.
Oh and the X.25 comment? Well in 1982 I was working in France and the only way for me and my colleagues who had come from MIT to get back to our mail at the MIT AI lab was a connect across the ocean on an international X.25 network hooked into MIT Multics and thence connect to the AI lab. After using fully interactive systems, it was painful to use a line-at-a-time system, so I figured out how to reset the X.25 front end to ship a whole packet for every character typed (packets had a maximum length so if you typed a really long line it would send a packet's worth, so I hacked it into thinking that a packet length was 1). Which was great, until shortly after the end of the month when someone "upstairs" had a heart attack at the size of the networking bill...
Actually this is backwards.
Line discipline is a historical artifact. Typically mainframes had IO front ends (AKA channel controllers) than managed IO so that the CPU (which BTW was what was charged for) could be kept busy and not wait around for users (by contrast CTSS, ITS and later machines like the Alto expressed an alternative, radical idea which was that the computer was there to support the user). Basically once a line was ready it was submitted by pressing the enter key and then its process was unblocked and processed the data. (Nowadays we just queue an event on the main thread...essentially the same thing!).
Likewise, a number of early network protocols like X.25 would charge per "line" (more about that later).
Unix was originally written for the PDP-7 (& later 11) which were minicomputers that didn't have channel controllers (in fact the earliest arpanet interfaces that weren't IMPS were PDP-11s acting as networking channel controllers for PDP-10 mainframes). Since IO was done by the kernel, you didn't want to to an expensive context switch for the common case of just reading a character and putting it into an input buffer.
So despite the comment quoted above, the true Unix model would have been for the kernel to have been agnostic and for each program to decide how it wanted to handle character input. But that would have been too expensive, so a more pragmatic approach prevailed.
By the way there are all sorts of other fossils in the TTY system. Multics used # to delete a character and @ to rub out the whole line -- a legacy of printing characters that persisted into Unix for years ###### decades. This seems weird today, but originally Multics (and later Unix) didn't have traditional line disciplines, or even control characters, much less select(). So it was handy to be able to essentially do immediate mode editing right in the input buffer.
Another fossil is that vi is just a visual mode grafted onto ed (clone of Multics qed IIRC), which was an editor with commands based on line-at-a-time IO.
ITS got proper IO virtualization first (and the predecessor to select, and extended it to the network with SUPDUP, later also implemented by Multics and eventually Unix, which made using Emacs possible) and actually had a more general version of select() before Unix was written, but at the time it was considered exotic.
Oh and the X.25 comment? Well in 1982 I was working in France and the only way for me and my colleagues who had come from MIT to get back to our mail at the MIT AI lab was a connect across the ocean on an international X.25 network hooked into MIT Multics and thence connect to the AI lab. After using fully interactive systems, it was painful to use a line-at-a-time system, so I figured out how to reset the X.25 front end to ship a whole packet for every character typed (packets had a maximum length so if you typed a really long line it would send a packet's worth, so I hacked it into thinking that a packet length was 1). Which was great, until shortly after the end of the month when someone "upstairs" had a heart attack at the size of the networking bill...