How to be unix-y in eleventy-billion easy steps
It frequently comes up that I’m writing little utilities at work to do various things. I’ve gotten into the habit of adding at least “usage: …” and “—help” options to almost every program I write because life is too (short|long) to be re-reading the source code to figure out what a program or utility does.
I usually end up doing a bunch of “ls —help”, “grep —help”, “cat —help” to triangulate what the help and usage lines for a typical program might look like, but I have come across some guides that begin to codify what unix “feels like”, and look to be extremely strong references to point to when trying to figure out the best way to write a program or how to pick names for command line arguments and options.
The two grand-pappies, The Art of Unix Programming and GNU Coding Standards are crucial documents to understand.
The two surprising finds in the above documents are the standard list of long options and short options from -a to -z.
Forver and a day I am trying to figure out what to name my program options and these two guides definitely help. It allows me to definitively say you should use -c … for “command” instead of -r … for “run” because -r means recurse or reverse.
“I wish to learn the Great Way of Unix”, he said “but the command line confuses me”.
Master Foo turned to the end-user. “Tell me”, he inquired, “why do you seek the Way?”
“I am discontent with the software I see around me”, the end user replied. “It neither performs reliably nor pleases the eye and hand. Having heard that the Unix way, though difficult, is superior, I seek to cast aside all snares and delusions”.
[source…]
Whenever you can, follow the above guides so that your software is reliable and pleases both the hand and the eye. Think of the end user (even when that end user is yourself) and you will be enlightened.
11:13 CST | category / entries
permanent link | comments?