Wandering Thoughts archives

An example of Unix's slow fossilization

If you walk up to the console of some Linux machines that have their capslock turned on and try to log in, an interesting thing happens:

keyx login: CKS
PASSWORD:
[...]
CKS@KEYX:~$

(This works with Ubuntu 6.06, but not with Fedora Core 6.)

Why does this happen?

Once, long ago, there were terminals that only did upper case, and there were people who wanted to connect them to Unix systems. So Bell Labs put a very special hack into getty: if it saw a login name that was all in upper case, it assumed that you were using such a terminal, lower-cased the name, and set a special terminal mode where lower case was converted to upper case on output and upper case converted to lower case on input.

(Of course this doesn't work very well if your password has any actual upper-case characters. Or your username, or the names of your files, or any command options, or etc etc. People who needed this hack were presumably going to avoid all of that.)

It has probably been at least twenty years since such a terminal was connected to a Unix system. In all that time, very few people removed this feature, and so it lurks around many systems to this day. Including systems reimplemented from scratch, where people can't even claim that it was less work to leave old code alone instead of removing it.

(To be fair, this seems to have been removed from the latest version of the Single Unix Specification. Also, FreeBSD and OpenBSD seem to not support 'stty lcase', although Linux does, which I find ironic.)

A small annoyance with Unix wildcards

Here's a small irritation with Unix wildcards: there's no generally recognized wildcard (or small set of wildcards) that matches all of the files in a directory, including dotfiles but excluding . and .., so that you could easily match all of a directory's real contents.

A plain * doesn't match dotfiles; * .* matches dotfiles, but includes . and .. too. About the best you can do is

* .??* .[^.]

However this blows up if there's no single-character dotfiles. This is a general defect in any multi-wildcard scheme, of course; the more wildcards and the more obscure they are, the more likely you are to have one that doesn't match anything.

I believe that some shells have a .* wildcard that doesn't include . and ..; on quick testing, zsh is one. (Bash and ksh seem almost able to do it but not quite, as far as I can tell.)

Interestingly, the behavior of * not matching files that start with . goes back at least as far as V5 Unix. (The V4 Unix sources have apparently been lost, and the V4 and V5 manpages are not precise enough to say whether the behavior existed in V4. If you are poking around this stuff at tuhs.org, it is helpful to know that in V6 and earlier shell globbing was done by an external program, /etc/glob; the V5 source is here.)

It's interesting to see that fairly complete shell wildcard support goes back very far in Unix history. Third Edition, released in February 1973 and the oldest Unix that tuhs.org has useful stuff for, already has *, ?, and [...] (including character ranges with -). (Since the V3 ls has a -a option to reveal dotfiles, I suspect that even V3 * wildcards didn't match dotfiles.)

Bonus trivia: the oldest ls options, present in V3, are -l, -t, -a, -s, and -d. V4 ls grew -r and -u, and after that you can go digging for yourself.