Yes, mindreading is tricky, but sometimes you don't need to read minds to just work with the user.
... but don't get me started on people who think it's ok to use a single hyphen to start a multicharacter option, or don't let you put multiple single character options after the single hyphen...
-? has been a common switch for decades. I've been implementing it (along with the synonyms -h, --help, etc.) in all of my programs since about the '90s.
I suggest supporting at least all of the following: -h, -help, --help, -?, /h, /?, help, <no flag> (if possible). Other flags don’t have to follow these rules, but I think help can be an exception.
And maybe you should print the help any time the user enters a bad command.
I'm just saying that I hadn't realized programs did that. And I've been around a long, long time. I guess I'm just blind.
-h/--help are all I ever see in macOS CLI tools, in any case.
There are quite a few older programs that do that, including ImageMagick and FFmpeg.
exit is unambiguously broken syntax, it doesn't fit into what the REPL promises, it's an error.
newbies to unix need to learn about Ctrl-D, and it should be taught. But it should not be the job of every tool to teach that lesson, it's one step removed from QWERTY. There are actually apps that break Ctrl-D and they are another abomination in the direction of newbie hand holding.
Even for low hanging fruit. eg, `exit` in Python can be redefined as a variable - so if I do that and then type `exit`, should it print that value for me or quit the REPL? Is it better to guess, or just not encourage the user to do the wrong thing?
If I make `-?` print help, what happens when I want to define `-` as "read the following text as input" and then users start getting bizarre behavior instead of the help file?
You can probably come up with ever-fancier ways to work around this, but that takes effort, and more testing, and more code...
I'm not sure what that means, but if you're saying that you would want your program to interpret "-?" as though somebody had run it with no option at all and then provided a question mark on the standard input, that's really obnoxious and grounds for torches and pitchforks from all users.
Look, on a command line, a bare hyphen, given as an argument where there might otherwise be a filename, can reasonably mean "read from the standard input" or "write to the standard output", but only because it's been so common for so long. As an alternative to it, you can just use standard input/output by default, or you can just punt and make the user give you something like "/dev/stdin".
In any other context, a hyphen introduces an option that modifies normal program behavior. If it's a single hyphen, then the option name is a single character. If it's a double hyphen, the option name is the rest of the argument up to any equal sign. It should consist of complete words and be in `kebab-case`, not `snake_case`. But even if you violate those rules, it's a far more basic rule that an argument starting with a hyphen is an OPTION NAME, not arbitrary data.
And the options "-h", "--help", and I guess maybe "-?" and "--?" are pretty much universally used to mean "print help about how to use your program". Changing that is insane.
I know that code on on Windows does horrific stuff (including pretending it's freaking RSX-11 and using slashes of all things). I know that some really old UNIX stuff written in the bad old days also breaks the rules. But even those don't just arbitrarily redefine what the hyphen means. Redefining absolutely everything under the user, to the point where they can't even guess how to ask for help, is just crazy.
the_command -foo
-foo: No such option. You probably meant --foo
And if you've got something like 'sed' overwriting the input file (-i), it'd better make sure the flags are exactly as documented.
git psuh
[alias]
psuh = push
I personally have "ull = pull" and "ush = push" in this section, together with "alias gitp='git'" in my ~/.bash_aliases because of how often I type "gitp ull".