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.
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”.
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.