unix

Every time I set up a new machine, before I have a chance to copy my config files from some other machine, I have to log into Zsh. Now, Zsh when I’ve customised it is very nice. Zsh without my customisations is perfectly usable. But, in some fit of low self-confidence, the Zsh developers appear to have become convinced that Zsh without any customisations is a horrible, horrible place to be, akin to the San Francisco Gay Pride Parade taking a wrong turning and ending up in Deliverance country. Nowadays, every time I start Zsh without having any config files, I get badgered to create some.

There doesn’t seem to be any global config setting for it, so I’m guessing it’s hard-coded in. The only way to avoid it is to do what it tells you and create, at the very least, an empty .zshrc.

(It’s possible to chmod 000 $MODULE_PATH/zsh/newuser.so, but this will only work until a new version of zsh is installed. Debian users may want to look at dpkg-statoverride, the rest of the world may be buggered.)

In a not-very-recent (March ‘07) edition of the UKUUG newsletter, there’s an article by Clive Darke complaining about the use of external programs to do things that ‘both Bash 3 and ksh93 support’, insisting that you should use the builtins for textual substitution, for example, instead of piping a string through sed.

This is madness. Relying on fancy shell features may improve performance through not having to fork and exec every other line, but it is sick and wrong. It means that all those systems without bash are unable to use your script. In fact, it means all those systems where bash is in a different place are unable to use your script; most people who write bash scripts as opposed to shell scripts seem to assume that bash is /bin/bash, or worse, /bin/sh, which is only common on GNU/Linux systems. It’s even worse in the case of ksh, which is much less widespread on the systems I’ve used, since most versions of it aren’t free software, and there’s several different semi-incompatible versions of it anyway even without getting into the bat-shit-crazy-proprietary-Unix-vendor-extensions that people like Sun and IBM insist upon inflicting on the world.

If performance matters, don’t use a shell script. If performance really matters, you should be using a compiled language anyway, since an interpreted language like shell is always going to be slow.

If portability matters, and you can’t get by with just POSIX sh and sed and awk and everything else, don’t use a shell script. Python, Ruby, Perl, are all designed to behave in the same way across platforms.

(Towards the end, he mentions that it can be more of a challenge to write a good program in ksh than in other languages. I can’t fault him on this, but I’m confused as to why he thinks this is a good thing…)

I find it interesting that Unix commands that consist of an object and a verb put the object before the verb.

English, the first language of the original programmers (and many since then) doesn’t actually do that; there’s two possible groupings it could belong to.

Example: cdrecord, useradd

• Subject Object Verb: “I CD record”. “I user add”.
• Object Verb Subject: “CD record I”. “User add I”.

The first is the most common order, though apparently rare in European languages. The second is the rarest, apparently used mostly by some rather obscure languages and also Klingon. I’d be interested to learn why it’s so common in Unix.

After tonight’s TermiSoc tutorial, I’ve finally gotten around to starting a Unix FAQ. It’s here. Feel free to post questions.

Yes, I know this is a little late. That’s because I moved furniture around and then decided to take the opportunity to install a second CD-ROM drive, which lead to mucking around with jumpers. Who knew that setting the master to Cable Select and the slave to Master would have such interesting results?