Wandering Thoughts: Recent Entries For 2012/06/25

Why sophisticated line editing is not in the kernel

At the end of my previous entry on TTY line disciplines I wrote:

Given all of this, you might wonder why sophisticated readline style editing took off as user level code (both in programs and as various libraries) instead of being integrated into the kernel. [...]

Well, let us start out with what we could call the pragmatic reason but should more honestly call the political one: it is a lot easier to add something to your user-level program than to get it included in any Unix kernel. Kernel developers are usually very conservative about adding features; getting them to accept sophisticated and thus complex line editing in the kernel would have been an uphill struggle (one involving a lot of arguing) even with working code. Then if you go this added to the new version of some Unix's kernel it might take more years for it to filter out to systems in the real world, to be reluctantly adopted by other Unix variants that you want your program to work well on, and so on.

(And just imagine the ferocious arguments over whether the kernel should support vi style editing, Emacs style editing, or both.)

By contrast you can add readline line editing to your own program as a small matter of programming and you don't have to argue with anyone about it. You can ship immediately and it works on all Unixes that you support. Apart from any other issues, it should be unsurprising that people opted to implement sophisticated line editing themselves at the user-level.

But there's a technical reason too, and that's filename completion (and more sophisticated completion as well). A not insignificant amount of filename completion needs to know things like someone's home directory or the current value of an environment variable (or a shell variable), so that it can complete things like '~/...', '~user/...', '$THING/...', and so on. All of these are more or less inaccessible inside the kernel, and so completion using them can't be supported in a kernel implementation of sophisticated line editing. And this goes even more so for more sophisticated completion such as completing command line arguments, hostnames, and so on, where the information needed is pretty much totally beyond the kernel (at least in practice).

(Even something as apparently simple as completing program names is subject to this twice over. First, what programs are available depends on what $PATH is. Second, in something like gdb you don't complete program names you complete the names of internal commands, and what commands are available is not something that you know from outside the program.)

So if advanced line editing was supplied by the kernel instead of user-level programs, it wouldn't be anywhere near as sophisticated as it is today; at most it could do relatively simple filename completion.