Hacker News new | ask | show | jobs
by acabal 4254 days ago
Great article. The other thing I've always wished for command-line tools is some kind of consistency for flags and arguments. Kind of like a HIG for the command line. I know some distros have something like this, and that it's not practical to do as many common commands evolved decades ago and changing the interface would break pretty much everything. But things like `grep -E,--extended-regexp` vs `sed -r,--regexp-extended` and `dd if=/a/b/c` (no dashes) drive me nuts.

In a magical dream world I'd start a distro where every command has its interface rewritten to conform to a command line HIG. Single-letter flags would always mean only one thing, common long flags would be consistent, and no new tools would be added to the distro until they conformed. But at this point everyone's used to (and more importantly, the entire system relies on) the weird mismatches and historical leftovers from older commands. Too bad!

7 comments

How to be Unix-y in Eleventy-Billion Steps.

http://www.robertames.com/blog.cgi/entries/the-unix-way-comm...

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

--Robert

http://www.catb.org/~esr/writings/taoup/html/ch10s05.html lists alternatives for each short option, so which do you choose?
Actually most of them are quite consistent since POSIX published guidelines for it - and the only inconsistencies are historical exceptions:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...

(I'm not so convinced that long options are a good thing, as evidenced by the --extended-regexp/--regexp-extended and other little "was it spelt this way or that?" type of confusions. It's not hard to remember single letters, especially if they're mnemonic.)

Long options are very nice to use in scripts as they are somewhat self-documenting. Compare:

    curl -kLIiso example.org www.example.org
versus:

    curl --insecure --location --head --include --silent --output example.org www.example.rog
And of course as a practical matter, with short opts you'll run out of characters eventually, and meaningful mnemonics before that.
You're right, myriad popular tools are not totally consistent (ls -h and du -h are similar but grep -h is very different). There is a bit of hope however--the GNU folks have documented lots of the options currently in use so you can try to find one that fits when you build new tools: https://www.gnu.org/prep/standards/html_node/Option-Table.ht...
I've often thought this - that xkcd.com/1168/ is funny is a terrible embarrassment. I would also like to add that manpage syntax help should be standardized and machine-parseable. I had an idea recently to auto-generate GUIs for command line tools from the manpage syntax line, but it turned out that while such lines look precise but cryptic, they are often in fact highly ambiguous, nonstandard, and still cryptic. This seems broken to me.
Blame man(7), have a look at mdoc(7): Semantic markup for command line utilities: Nm : start a SYNOPSIS block with the name of a utility; Fl : command line options (flags) (>=0 arguments); Cm : command modifier (>0 arguments); Ar : command arguments (>=0 arguments); Op, Oo, Oc : optional syntax elements (enclosure); Ic : internal or interactive command (>0 arguments); Ev : environmental variable (>0 arguments); Pa : file system path (>=0 arguments)
Linux kernel tools solves this, but the help looks cryptic and is difficult to parse by a human(such as myself).

I can't find documentation on what I mean, but try ip --help

Are you referring to GNU sed? Other sed implementations I know of actually use -E for extended regular expressions support. I could never understand why GNU picked up -r for sed...

As for dd, it came from a non-UNIX OS and kept the original syntax.

It would be easier to write a wrapper that called the real commands. You would have to writer a wrapper for each command, so it's still a lot of work.