Wandering Thoughts archives

The fun of awk

I like awk, I really do, but sometimes it really irritates me. Take, for example, this fun little awk program:

awk 'BEGIN {print "5" == "05"}' /dev/null

You might rationally expect this to print '1' (awk's boolean truth value). As I found out once, you would be sadly mistaken; this is false, presumably because awk winds up doing a string comparison instead of a numeric one. Too bad if you're reading one set of fields that are zero-padded and one set that aren't.

(The workaround is add 0 to the "05" to force the numeric interpretation; "5" == ("05"+0) comes out true.)

This shows two drawbacks of the sort of magical conversion between numbers and strings that awk does. First, this sort of stuff involves heuristics, and heuristics are inevitably wrong sooner or later. And second, if you do not have the fine details carefully memorized you can wind up surprised.

At the same time such magical conversions live on because they are oh so very handy when you are banging things in a hurry. Considering the sorts of things that awk was designed for, this is completely the right decision for it; having to write explicit Python-style conversions all the time would probably drive me up the wall, however much I like them in Python.

Dear applications: WEP keys are not passwords

Every so often, I have the dubious pleasure of entering WEP keys in order to get access to some wireless network around here. Invariably, the applications treat the WEP key like a password, and has me type it in a text box where all the feedback I get is a '*' for each character that I type.

(We use WEP keys mostly as a way to keep random passers-by out. Not so random passers-by can crack the WEP key, at which point other precautions keep them from doing anything useful with their new-found wireless connection.)

Almost no feedback is okay for a password that is relatively short and that you will type frequently, so that you get good at it. WEP keys are neither; for example, a 128-bit WEP key being entered in hex mode is 32 characters that I will type once in a blue moon and in fact I am not typing it from memory, I am trying to transcribe it from a piece of paper. In this sort of situation, lack of effective feedback is frustrating, especially because the only way to correct any mistakes is to try entering the WEP key again and see if it works this time around.

And both in theory and in practice, WEP keys are not passwords. They're not in theory because a WEP key can be cracked with relative ease, so trying to keep it secret gets you almost nothing; they're not in practice because they are almost never entered in a situation where obscuring what you are entering has any effect on security.

So: application authors, please stop making everyone's life harder; just use a plain text box for entering WEP keys. (For bonus points, give us a better interface for entering hex keys, since those aren't going to be very readable even in plain text.)

An advantage of interpreted languages

One of the useful things about interpreted languages like Python for programming, especially system administration, is that there is no distinction between the source code and the executable program. This means that you never have to play the exciting game of 'where's the source, and for that matter the build instructions, and does it even build with a modern compiler?'

(I once had the interesting assignment of converting a program written for the V6 Unix version of C into something that would compile on a more conventional C compiler. For those that have not encountered it before, the V6 version of C put the operator on the right side of the = for in-place assignment (eg =+ instead of the modern +=), among other differences.)

This means that when I write something in Python, Perl, or so on, everything is right there and complete; I do not have to worry that I may be abandoning co-workers with infrastructure that they have no idea how to reproduce. I find this reassuring, because it means that we have at least a fighting chance if something goes wrong.

(I once heard a story about a pretty much irreplaceable machine, which was that way because the developer of the program running on it had died and no one had any idea where the source code was. That's the kind of thing that can all too easily lead to an appearance in comp.risks.)

The Bourne shell is not a programming language

Before you rise in righteous indignation, let me say that that doesn't mean that you can't write programs in the Bourne shell; you can write programs in anything that's Turing-complete if you try hard enough. It's just that you shouldn't.

The problem with writing programs in the Bourne shell is the same as writing programs in any other highly constrained language: your programs come out all but unreadable because they are spending most of their time getting around the inherent limitations of their environment. What your program is really doing winds up being expressed only indirectly, because you have no good direct way of saying it, and in turn this makes it hard to do anything but run the program and hope it works.

This leads to an obvious question: what's the boundary between a script (which the Bourne shell is fine for) and a program? I'm not sure, but I sort of think that if you need more than a few lines of comments, it's a program.

(Or to put it another way: if it's not obvious what it does and how it works, it's a program.)

Unfortunately I don't think there's a really good Unix programming language to replace the Bourne shell, which is one of the reasons that writing programs in the Bourne shell remains so tempting.

On standard interfaces

One of the things that is usually cited in favour of Macs (and Windows) is that the core of the GUI interface is more or less standardized, unlike many Unix programs. For example, consider the huge disagreement among xterm, GNU Emacs, and Firefox about how simple copy and paste works; surely the Mac or Windows way is better than that.

I don't think so.

My view is that it is easily possible to overdo an adherence to standardized interfaces, because standardized interfaces only really matter if you are only going to use a program occasionally. As an occasional user, standardized interfaces mean that you can carry experience over from program to program; you may be unfamiliar with a particular program, but you're familiar with how to do general things.

But if you use a program often enough, you are not going to forget how to use it and you are better off with a good interface that helps you, one that is tuned to the particular details of the job at hand. For example, xterm's copy and paste interface may be non-standard but it is excellently tuned to make it really easy (assuming you have a three button mouse, at least).

(Serious editors are another example of this; all of them have arcane advanced interfaces that you have learn over time in order to be really productive with them. Sticking to just a standard interface would give you only a basic editor with limited or awkward features.)

(This is probably an obvious observation. I just feel like writing it down, if only for myself.)