> 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…