Hacker News Reader

Comment by krnlpnc | Hacker News Reader

There’s a special place in hell for those pushing long argument names with single hyphens.

One hyphen is for shorthand, two for long name.

Funnily enough, find(1), one of the oldest Unix tools to still be somewhat actively used, had those from the very beginning. Although, arguably, find(1) can be considered an interpreter of a language of its own, like sed(1) and awk(1), as opposed to a utility that accepts flags.

See the Unix v5 man page source: https://github.com/aap/unixman/blob/master/v5man/man1/find.1. (If anyone has a link where those are rendered, please let me know.)

According to Dennis Ritchie, find(1) was developed by a different group at Bell Labs which explains the difference in style. “…We were somewhat put off by the syntax of their things. However, they were clearly quite useful, and they were accepted.”

http://doc.cat-v.org/unix/find-history

Open a terminal in a directory;

Find Files $ find|sort|egrep -i 'file.name'

Find Text $ find|sort|egrep -iR 'text.in.files'

"It came from NJ" was a pejorative at Sun. Like, if you were staring at some awful piece of code in Solaris, and you were like, "who wrote this??" and asked around, and the answer you got was "it came from New Jersey", that meant it was part of SVR4.

Yes. Also for people who insist that you use —-help but won’t accept -h.

>$ footool --help

Unrecognized bar "--help", aborting!

Use: "footool help" to display usage information

>$ man footool

No manual entry for footool

Probably a typo but requiring `—-help` with em dash would be another level of evil.

The worst offenders are the ones who even put the logic in to let one know that they knew exactly what one meant, but instead of accepting it they purposely throw an error, and adding insult to injury, telling one what one should have provided.

Those people are psychopathic abusers, and for some bizarre reason seem to be drawn to computers. I haven't figured out why yet.

Like “exit” in the Python repl, Which,knowing perfectly well what you wanted to do, will bark back “use exit()”. And only now, decades later it’s actually being fixed, but you still have evil bastards complaining that it should not do what you expect.

Yes. git push does this.

> long argument names with single hyphens.

Also --long_options_with_snake_case

Might I caution you away from any tools built with the Abseil flags library.

Looks like a leaky abstraction, in which a negligible amount of time saved in development (by mapping command line options directly to identifiers) results in UX woes.

For whatever reason, the Java tools have had these from the beginning. It's rubbish but you get used to it. More recently, they have been using double hyphens for long flags. So now you don't even know which it will be! And of course, there are extra options hidden under -XX. And flags which take arguments use inconsistent separators. So a command line might look like this:

  java -agentpath:/opt/agent.jar --module-path /opt/modules -XX:HeapDumpPath=/tmp/heapdumps

> For whatever reason, the Java tools have had these from the beginning.

The double hyphen thing was standardised by the GNU project.

James Gosling didn't like GNU (I think based on something that happened in the Lisp days?).

If there are lots of long argument names and many of them are freqently used, there is not much point for shorthands though. Better to treat single-letter "shorthands" as their canonical names in that case (e.g. compilers). Of course you can still argue that all of them should have two hyphens.

Oh, if only I could upvote this more! And even more torture and suffering is reserved for those morons who use --long-options "because they are easy to remember".

The LSI MegaRAIDb proprietary command line tool, MegaCli, is guilty of this and several other transgressions...

Clang, swiftc, etc. would like a word with you... :)

(It bothers me too.)

-fpic is a single letter option, -f, followed by the parameter pic. Clang still uses two hyphens for long options including --help.

There are tons of options that start with -f and can't be decomposed in that way [1, e.g. -framework]. They are essentially atomic options with a loose naming convention.

[1] https://clang.llvm.org/docs/ClangCommandLineReference.html

Correct. You cannot use “ramework” as an argument to “-f”. Instead use two dashes and it is unambiguous.

It took me some thoughts to realize what you wanted to say, and you are incorrect: there is no single option `-f` in cc options! `-f` is just a common prefix of hundreds of independent options, like `-fsanitize=...` (which can't be used as `-f sanitize=...`). As I've iterated before, those prefixes mostly represent broad categories of options and not hard and fast rules: `-g` for debug, `-i` for directories, `-m` for target architectures, `-W` for warnings, and `-f` for virtually everything else.

But maybe we should talk about the lack of space character between the flag and the argument…

That's just how short options with arguments work in getopt POSIX land: '-oARG' is equivalent to '-o' 'ARG' just like '--option=ARG' is equivalent to '--option' 'ARG' (for GNU long options). This means that you cannot chain any other short options after one with an (optional) argument but otherwise does not cause any problems.

Yes not every Linux/unix arg parser conforms to posix, some require a space, others do not.

saneclang, saneswift, (sanegcc?) cli wrappers around clang, swift which fix the insane porcelains of those toolchains.

We built a million GUIs for these, why did we never build CLIs for bad CLIs?

To be fair to Clang, the -arguments are inherited from GCC for compatibility (which perhaps inherited them from other CCs) and then extended from there in the most consistent way possible. Similarily, clang-cl supports cl.exe-style flags for drop-in compatibility.

No, that's just GNU.

Originally, yes. Now it's much more widespread, because it turned out to be a good idea to have consistent argument syntax.

By that strange logic, all the developers of the Go Programming Language deserve a special place in hell ?

Why do I have to laboriously type two hypens for a readable option ? Causes finger pain especially when you have a large number of options.

> Why do I have to laboriously type two hypens for a readable option?

Suppose you have a CLI app that supports the following parameters:

  -e extrapolate your foos
  -h highlight your bars
  -l line up your bazs
  -p print the aforementioned as they're being processed

So you might run the CLI as:

  cli -ep
  cli -hp
  cli -ehp
  cli -lp
  # a bunch of other combinations, including
  cli -ehlp
  # but since the order doesn't matter, also
  cli -help

Do you see why that might be a problem with the short parameters?

Now, most applications would reserve -h for help, so instead you'd still end up with the following:

  cli -help
  # so, the user wants to
  # -h get help information
  # -e extrapolate your foos
  # -l line up your bazs
  # -p print the aforementioned as they're being processed

which does not make a lot of sense. That's why you'd normally have something like:

  -e --extrapolate extrapolate your foos
  -h --help get help information
  -i --highlight (-i seems close enough) highlight your bars
  -l --line line up your bazs
  -p --print print the aforementioned as they're being processed (though this is just an example, a lot of packages also use -v --verbose)

So then there's no such confusion:

  cli -ielp # makes sense, a bunch of commands
  cli -help # still doesn't make (much) sense, help shorthand mixed in with arguments for data processing
  cli -h # makes sense, short hand for --help
  cli --help # verbose help command
  cli --highlight --extrapolate --line --print # also makes sense, just more verbose

I don't get this. Why did you reserve '-h' for highlight in the first example ? And then you chose the long option form "-h/--help" to say the problem is now fixed. It seems an entirely artificial problem made by an originally bad choice. And has nothing to do with lack of double hyphens.

"go -h" is same as "go help".

> I don't get this. Why did you reserve '-h' for highlight in the first example ?

Well, for the most part i wanted to show that:

  cli -help

might actually be interpreted as 4 short arguments (grouped with -), instead 1 long argument (--), these are the same if you go by GNU conventions:

  cli -h -e -l -p
  cli -help

Thus using -help like you're offering doesn't make sense whether -h is for "help" or for "highlighting" (example of a fictional action that the CLI might support) or anything else. In practice you won't see many software packages reserving -h for anything but help, but -elp would be a stupid example.

To understand this better, consider the following in a case where the file you want to process is literally called "help" with no extension (which is valid):

     cli <ARGUMENTS> <FILE_TO_PROCESS>
  1) cli -h -e -l -p help # uses 4 arguments on a file called "help"
  2) cli -help help       # uses those same 4 arguments on a file called "help"
  3) cli help             # processes a file called "help" with no arguments
  4) cli -h               # invokes whatever is under -h, be it help/highlight or anything else
  5) cli --help           # the help argument, if present
  6) cli --highlight help # the highlight argument, if present, on a file called "help"

With what you're offering, options 1, 2 and 3 probably wouldn't do what you expect them to, unless you reject GNU semantics.

Ok, I see this specifically a problem with GNU option collapsing, overloading help and not returning an appropriate error for invalid usage when invalid options are passed to '-h'. Frankly, if I wanted to collapse lots of options, I would either make another option simply for that (or option concatenation option like '-c') or introduce sub-commands. Better design and more human-memorizable.

But thanks for detailed response. Upvoted for explanation. :).

The first rule of writing Go CLI tools that don’t drive users insane is to use “github.com/spf13/pflag” instead of the “flag” standard library package.

Rather annoyingly that is often the only third party dependency required…

Reply on news.ycombinator.com