Hacker News Reader

Comment by DrBazza | Hacker News Reader

The consistency rule I follow in any CLI tools I write: options are optional, required are commands or arguments.

Anything with `-` or `--` is an optional. Just like all the basic unix/linux tools. You don't have to `ls --thing` to list a folder, just `ls`. Or `cat --magic --args the_file` and so on.

If I require an 'option', it becomes a command or an argument for the command, i.e. `tool --list-files` becomes `tool ls`. Copy for example: `cp src dest` works, `cp` on its own, doesn't.

I even tend to write extensible CLI tools, `tool-ls` will drop into the same folder as `tool` and running `tool` will detect `tool-ls` and present it in the list of commands. Just like git.

View on HN

This only works with CLI that take a few arguments. If you're writing a CLI that requires 5+ arguments, then positional arguments are very hard to remember the order of. -- arguments make that easier.

This is correct.

The name option is misunderstood. You have options. Sometimes you just have to pick one.

Try going to the ice cream shop and ask for an ice cream but refuse to give them the size, flavour or the type of dip. Tell them it's optional and you shouldn't need to provide this information on order to get ice cream.

Chances are you're suddenly getting a new set of options. A. Kicked out. B. No ice cream. C. Gigantic truck size vanilla icecream with garlic dip and tuna flavour. That'll be $79.99.

You have options but sometimes you have to pick a few.

If you argue for positional arguments, try ordering ice cream: large chocolate strawberry.

Does that mean chocolate flavour or dip?

One of my huge frustrations is the inconsistency between various apps or even in the same app.

Sometimes it's "executable -help" or "executable --help", sometimes it's executable -h, or --h.

I also find it really annoying when running a bad/wrong/typoed command doesn't give you a "You wrote fkuc but did you mean ...." those are super helpful.

IMO, if you use --help, you also should be using -help, and -h --h, unless you're using C and c to seperate two different commands. Which I don't like AT ALL. Don't make --help show help but --HELP show something different. Use a different word/letter.

I write TUI apps ALL the time and it's not hard to do ANY of this. It's super easy in go and ruby. There are two big things I do - I add CLI flags that you can run directly - "executable --help" which does the same thing as opening the TUI app with a nice little TUI menu where anyone can use it and select their options and put a couple of inputs in to get what they want done. So, if you DON'T want the potentially slighty slower of uising the TUI vs a CLI command with a few flags you can just run the commands directly.

Hell, if someone puts the wrong CLI --flag in instead of letting it just bomb with a *nix error have it echo the actual command flags. Don't make me have to dig around for commands.

And don't send me to your manpage with --help. God I hate that. Manpages sometimes are absolutely awful. I want ONE command flag that you made some esoteric word for, I want a nice concise list of the flags. I do NOT want a 5 page manpage written so dry and cumbersome that it's such a pain to read that we have other cheatsheet apps.. I ONLY want the manpage if I ask for the manpage.

> IMO, if you use --help, you also should be using -help, and -h --h

I tend to go by the paradigm of single dash for single character options, and double dash for full words (and common things like —-help should have aliases like -h).

That's interesting. Did you come up with that yourself or is that a common standard?

I've always wondered why the style of command flags wasn't "more" standardized after 32 years of Linux being around (not that thats the first time flags were introduced, just an easy stop so I don't have to dig into that since it's not super relevant).

So, maybe it is somewhat/completely standardized and I'm just not aware of where that information is?

I think your style would still frustrate me. I'd first type "executable -help" thinking that was probably the - and -- option, and get a command not found error. I wouldn't think that think we're using - and -- differently.

The --long-option thing is a GNU thing: https://www.gnu.org/software/libc/manual/html_node/Argument-...

I've never even thought about this. I think this is kind of strange

> An option and its argument may or may not appear as separate tokens. (In other words, the whitespace separating them is optional.) Thus, -o foo and -ofoo are equivalent.

Thanks this is super helpful I never knew this was a GNU thing.

Note that there's an opposite convention that I think originated with the BSDs, where -ofoo is equivalent to -o -f -o -o

That only holds when 'o' and 'f' are both boolean "flags" taking no arguments. If 'f' is more like --file=x then it takes an argument.

More specifically, getopt(3) in POSIX lets programmers very this by giving a format string. "o:f" would make your example parse as "-o" "foo" while "of:" would make it parse as "-o" "-f" "oo" and an "of" format would make it parse as you describe, "-o" "-f" "-o" "-o".

( darnir mentioned parts of this above: https://news.ycombinator.com/item?id=38968612 using the term "single character flags" to indicate no argument. )

Also, while --long-option is GNU, gcc which is perhaps the aboriginal GNU command-line utility uses single dash as in, e.g. `gcc -pipe`, though it also accepts `gcc --help`. CL syntax remains quite varied in the wild.

That used to be a fairly common standard. You'll notice nearly all the old GNU / BSD tooling use this paradigm. It is even codified in GNU's coding principles. In fact, when you do that, you can even merge all the single character flags together. For example, I can type, `ls -lah` instead of `ls -l -a -h`. Pretty handy.

My pet peeve is commands not supporting -h for help and making me write --help. This is especially worse when the command already supports single character arguments.

Dont forget when it provides -help but not --help, and -h is is an invalid argument.

Definitely not my idea, but is encouraged by built-in tools like python's argparse [0] or node's util.parseArgs [1] which definitely guide you toward's this "short"/"long" style.

[0]: https://docs.python.org/3/library/argparse.html

[1]: https://nodejs.org/api/util.html#utilparseargsconfig

Oh man, you wanna be triggered? Find a cli app that takes both -<word> and --<other> options, but wont accept --<word> or -<other>.

So rage inducing

Reply on news.ycombinator.com