The POSIX shell and the three sorts of Unixes
Avery Pennarun recently wrote Insufficiently known POSIX shell features, where he talked about a number of nice shell things that are not Bash but are instead POSIX shell features. Although he footnoted this in his entry, I want to draw your attention to how there are three sorts of Unix machines (or, well, Unixes):
- machines on which
- machines on which
/bin/shis POSIX-compatible but is not Bash.
- machines which have a POSIX-compatible shell, but it is not
Every so often some well intentioned person attempts to transition the first sort of Unix into the second sort. Busy sysadmins usually immediately reverse the transition because we have better things to do with our time than debug Bashisms that have crept into administrative scripts or, worse, explain to users why their shell scripts just broke and how no we are not going to do anything about it although we could because it is good for them, honest.
(Rewriting shell scripts to pointlessly avoid Bashisms is the very opposite of productive work. It's even less productive than browsing Slashdot, because there is some vague chance that you could learn something from Slashdot.)
The third sort of Unix is a pain in the rear for everyone. In many
respects it might as well not have a POSIX shell, because you can't
easily use it in portable scripts. If you are a big project like
redo you can work around the
difference and find yourself the right shell, but if you are an ordinary
person writing cross-machine shell scripts, ones that you want to run
without an installer step, well, you lose. Your scripts all start with
#!/bin/sh' because that's the only reliable cross-Unix name for a
Bourne shell, so you can't count on POSIX features.
Fortunately the third sort of Unix is mostly dying out. The largest holdout in our environment is Solaris, which we don't let users log on to and barely run anything on. Even then, the differences sometimes get to us.
Honestly, I suggest that you ignore the third sort of Unix unless you can't because you have one. And if you want to write portable POSIX shell scripts, make sure that you use the second sort of Unix right from the start. (Or that someone involved in the project does.)
Filtering, email, and differences from Usenet
Yesterday I told the story of how and why I started filtering Usenet and suggested that the same evolution applied (or would apply) to email. Well, maybe. Today it's time for a counter-argument:
Email is fundamentally different from Usenet in one core way. For the most part (and definitely if you were not a frequent poster), Usenet was simply free-floating information going by. Some of it could be useful and some of it could be interesting, but none of it was essential and none of it was specifically for you.
Email is not like that. Or rather, some email is not like that. Some email certainly is like that; it is the same sort of general free-floating information and notification and whatnot, where it doesn't really matter whether or not you read it. But unlike Usenet, some of the email you get is specifically intended for you and is in fact actively important. It is not just useful to read that email, you need to read it.
You may or may not care if your spam filters take out some of the interesting free-floating information email (it depends on how far along the Usenet evolution you are). But you definitely will care if your spam filters take out email that you need to read, because reading only some of that email is not good enough. This means that you can never have the sort of aggressive, throw away almost everything filtering on email that people wound up with on Usenet.
Or to summarize pithily: on Usenet it was acceptable to throw away some of the baby along with the bathwater because it wasn't your baby. In email, it is your baby and throwing any bit of it is not acceptable.
(Well, okay, you could see such aggressive filtering on email if email became Usenet-like, ie if people stopped getting this sort of important stuff by email, leaving only the Usenet-like stuff. I tend to think that this would be a net loss.)