4 ms·

> 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

> 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

lenkite 5y ago
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".
- KronisLV 5y ago
  > 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.
  - lenkite 5y ago
    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. :).

lenkite 5y ago

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

KronisLV 5y ago
> 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.
- lenkite 5y ago
  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. :).