3 ms·

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

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.

swozey 3y ago
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.
- TheCleric 3y ago
  > 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).
  - swozey 3y ago
    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.
    - tom_ 3y ago
      The --long-option thing is a GNU thing: https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html https://www.gnu.org/software/libc/manual/html_node/Argument-...
      - swozey 3y ago
        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.
        yjftsjthsd-h 3y ago
        Note that there's an opposite convention that I think originated with the BSDs, where -ofoo is equivalent to -o -f -o -o
strunz 3y ago
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.
- ranting-moth 3y ago
  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?

swozey 3y ago

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.

TheCleric 3y ago
> 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).
- swozey 3y ago
  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.
  - tom_ 3y ago
    The --long-option thing is a GNU thing: https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html https://www.gnu.org/software/libc/manual/html_node/Argument-...
    - swozey 3y ago
      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.
      - yjftsjthsd-h 3y ago
        Note that there's an opposite convention that I think originated with the BSDs, where -ofoo is equivalent to -o -f -o -o

strunz 3y ago

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.

ranting-moth 3y ago
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?