I've said it before and I'll say it again: the error "Option `--help` not understood, did you mean `-help`? Use `-help` to display program options." is one of the most insulting things a program can say to me. `--help` is the lowest common denominator. You have to support it. I don't care what your program has to special case in its parsing, just do it. If I knew your program's preferred syntax, I wouldn't be asking it for help.
My entire Linux experience is dictated by what’s installed by default on rhel and/or ubuntu.
I sorely wish it was as simple as "please deploy", and in days of yesteryear you could probably get away with that either yourself or if you were friends with the linux team, but those days are over now as far as I see.
For context, my opinion comes from being a security consultant for over a decade - I see a lot of other people's environments and how their organisations handle requests like this. Not every environment will have objections, but most won't add it as a standard package across the fleet.
Java was already two years in development at that time.
And after a bit of shower thinking, you know that alone time with nothing better to do but ponder the mysteries of the universe, things like black holes, the nature of light and the ascetic of the command line. I decided that single dashes were also sort of ugly and hindered readability, but there was a better way as hinted by the single most screwball command in the standard unix installation.
Yes it is I ( evil laugh ), that misanthrope actively making new cli scripts what use dd style arg=value
http://nl1.outband.net/extra/remv.txt
Actually the real epiphany was when I was doing some work with "megacli" the tool for lsi hardware raid management. I noticed that sometimes I could forget to add a dash to an argument. A little experimentation showed that no arg actually required a dash and the capitalization was ignored. it was like a huge weight was lifted from my shoulders, much better this way.
MegaCli -PdReplaceMissing -PhysDrv [1:1] -Array2 -row1 -a1
MegaCli pdreplacemissing physdrv [1:1] array2 row1 a1Likely inspired by JCL syntax!
The go tooling also has the irritating tendency to take a command like `go build --help` and say "oh, run `go help build` for details" instead of just printing out a list of possible options. Also: the details page doesn't always present you with a list of possible options, so you have to read each paragraph to see if there's an option relevant to your interests.
Short-circuit any typo may be dangerous.
Now, an argument can be made for including as many aliases for "help" and "version" as possible but that's a different story
So it's often not the case that a single person who made the decision to have a message that says "you asked for help, but you did it wrong; before I give you help you have to ask correctly."
>> aim wand at perodactyl
> I see no perodactyl here.
>> aim wand at pterodacyl
> I see no pterodacyl here.
Frustrated at my continuing mistakes, I decided to try to short-circuit their logic. Despite knowing the difference, I typed this:
> aim wand at bird
And the game replied:
> a pterodactyl is not a bird
I don't care how it's done. Heck, dump the help if you see any option with two dashes, if you're offended about long options. I don't care what other things dump help out too as long as --help does. But both -h and --help should always produce help, no matter what, no matter where you are, and I'd really like -help too, even if that is a bit more complicated. Though since I also want "a -h or a --help in the parameter list reliably makes it so that help is printed and NOTHING ELSE happens", "-help" should generally work as "-h" and "extra stuff that won't happen because -h is in play". It is an error for a program to both print the help and take any other action; should always do one XOR the other.
How about non English speakers who might be inclined to type —ayuda or something?
In 2025 I think it should be more obvious that the shell is just running a program and programs have a variety of entry points and the same program can be distributed in different forms and that they might not all be self documenting.
> What about programs with such simple CLIs that they don’t have help?
It is crapware
> about non English speakers who might be inclined to type —ayuda or something?
Come on… really?! Most utilities use heavily english for option names. Even the names of the utilities. Should we have “buscar” instead of “find”, or “schneiden” for “cut”? What about iger instead of “grep”?
That is just ridiculous! Please stop!
I think what some are going for perhaps is that all programs to be run in the shell support --help. I think it could be normalized further by having a shell function get help for a command. For most it could pass --help, but it could handle the exceptions. So instead of running "foo --help" you could run "help foo", and it would run "foo --help" or "foo -h" or whatever, and it would be like man except instead of meaning show a manual page it could mean ask a program to document itself.
See PowerShell commandlets for a related precedent: https://learn.microsoft.com/en-us/powershell/scripting/devel... Commandlets (shell functions) can annotate themselves and their parameters in a standard way, and then the shell's builtin help command parses that and presents it in a standard way. Though unfortunately this kind of integration only works for the commandlets, not arbitrary executables, because there's no standard for executables to expose such metadata to the shell.
I would guess you chose something like mapping "Global Regular Expression Print" to "Imprimir Globalmente Expresión Regular". But of course "grep" isn't really an acronym, but a contraction of the ed (and ex) command "g/re/p". Surely you don't mean to alter the syntax along with the words!
My Knowledge come from some archaic Sun manual. I wanted to find it, and everywhere it says print… I had it wrong.
Anyway the idea is to show that translating is always partial, ans a full translation would be a titanic and unproductive work.
I’m a native speaker of a couple of languages, and learned some more. So i have used computers in many languages. I hate command line translations, all are bad.
I’m BSD and Solaris guy, but when I’m in linux, I spect linux. It should be part of PORTING a program, if the option is not supported.
But asking for `--help` is unambiguous, and is in fact the lowest common denominator way to be explicit about it.
a) use bash-like behaviour of an unmatched glob turning into a bare word, e.g with zsh have `setopt NULL_GLOB`.
AND
b) don't have a file named, say, `-a` in the current working directory.
Try this:
touch ./-l
ls -?
That's... not what a common denominator means. It's far easier to check for `--help` or `-h` and print _something_ than write a whole document in a weird markup language for man.
man(1) is, provided that people produce man pages. It's also orthogonal and composable without interference: one can write a man page for commands that don't have man pages.
Flags are not, because commands parse their arguments in whatever way; all commands can accept arguments but arguments are also part of the operational interface contract. man(1) is decoupling all possible problems out.
It is also extremely obvious than `man foo` is side-effect free, whereas `foo whatever`, whether `whatever` can be `--help` or anything else, has unknown effects when the command is unknown.
Some argue that man pages are too rich; well the man pages can just also start with a summary identical to what a hypothetical `--help` flag would output.
Turns out this is the conventional `SYNOPSYS` title of section 1 man pages, and possibly the `OPTIONS` one; if these are absent or badly written then one could reasonably posit that a hypothetical `--help` flag output would be just as unhelpful; cue the wads of commands that "--helpfully" output `foo [-4236xXksirtTgsdv]` as help, which tells you nothing really helpful.
`info(1)` can burn in hell though.
These days, I'm positively surprised when I find man pages for a program, whereas I'm annoyed when one doesn't support --help.
They're absolutely trivial to generate these days, gone are the days of having to deal with roff, you can write a quite dumb markdown file and produce a man page out of it in short order.
https://github.com/sunaku/md2man/blob/master/EXAMPLE.markdow...
https://github.com/rtomayko/ronn/blob/master/man/ronn-format...
There are people arguing that? My feeling is that man pages are usually so thin as to be useless in 50%+ scenarios I need them. I really wished the culture defaulted to expecting all software to come with Info pages.
Rather:
b) don't have a file with a single letter name in your CWD, like `a`
Try this:
touch a
ls -?
I don't see it. What are you trying to show with 'a' instead of '-l'? Why would a file named 'a' interact with a glob like '-?'?
$ touch a
$ ls -?
zsh: no matches found: -?
$ bash -c 'ls -?'
ls: invalid option -- '?'
Try 'ls --help' for more information.
$ dash -c 'ls -?'
ls: invalid option -- '?'
Try 'ls --help' for more information.
$ touch ./-l
$ ls -?
.rw-rw-r-- 0 user 10 Feb 18:32 -l
.rw-rw-r-- 0 user 10 Feb 18:31 a'?' is glob for one character, '-?' means "dash followed by any character", and that's what I'd expect to be matched, and that's what my `ls` does.
but `a` is not "dash followed by one character" so the glob does not match a `a` file?
my haha nearby was wrong! I should have tested it :)
Normally, ls doesn't expand globs.
Why did you say to try "touch a; ls -?"? What am I supposed to see from those two commands?
If you already know the content, but accidentally made a typo and are trying to debug it, then reading the documentation isn't going to help. An error message pointing out the problem will help.
And at high levels, a referee role is probably similar to physician/lawyer where you'll have annual rule updates/changes, jurisprudence history of past rulings, and conventions/associations of referees where they will be spending money, time and effort when not on the field.
Now multiply the referee's game or league types by everything in /usr/bin
--help being an incorrect argument does the right thing, yes.
This is especially useful in situations where the help text is enormous (dozens and dozens of options).
MariaDB also doesn't print the entire manual when it goes "syntax error at ' OR 1=1". It makes no sense.
You can include "See --help for more information" at the end of every error to make sure everyone knows where to find that, though, since indeed not every program uses the same syntax for usage. 90% of the time I don't need a copy of a program's manual in my scrollback when I, say ,typo something or forgot that two options are incompatible. There is a reason scrollback exists and I use it for that purpose. I'll look up the manual or run --help in another terminal tab/window, or choose to run it in the current one at my own discretion thank you
Genuinely my least favorite thing in the terminal is when I forget some detail about... usually CURL, since they use the capitals AND the lowercase letter arguments for very different things. So I end up having to use the / command in `less` to search for some common word for 3-5 minutes because the manpage is so disorganized. We have a much better tool than the Terminal for viewing long-form text content, so maybe I just need to alias `man` to open a website that publishes manpages.
Some programs give a short help message when options are not understood. A good thing.
That said, in GNU/Linux a program that does not have --help is shitware.
`cmd --help`
Error: option - not understood. Use `cmd -h` for help.
Or this pattern that we find everywhere in golang-written tools:
$ helm --version
Error: unknown flag: --version
$ helm version
version.BuildInfo{Version:"v3.17.0", GitCommit:"301108edc7ac2a8ba79e4ebf5701b0b6ce6a31e4", GitTreeState:"clean", GoVersion:"go1.23.4"}
(The reason for this one seems to be that, in your CLI-parsing library, you have verbs that define what you want and flags that pass options to those verbs; 'show me the version' is a verb, so it can't be a flag instead. Without a verb, the program doesn't know what to do.
It's still infuriating, though, but at least it reduces the frequency with which -- is substituted for an em-dash (e.g. when sending commands to coworkers from your iPhone via Slack).
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/
"I got used to fish and vi mode which are not available when I ssh into servers, containers."
POSIX does mention vi mode as an optional feature.
"Allow shell command line editing using the built-in vi editor. Enabling vi mode shall disable any other command line editing mode provided as an implementation extension. This option shall be supported if the system supports the User Portability Utilities option."
Expecting there to be a safe invokation for "how do I use this damn thing" is 100% fair.
Are you on debian? Do an `/usr/sbin/e2scrub_all --help`.
$ e2scrub_all --help
e2scrub_all must be run as root
$ sudo e2scrub_all --help
[sudo] password for dan:
/usr/sbin/e2scrub_all: illegal option -- -
Usage: /usr/sbin/e2scrub_all [OPTIONS]
-n: Show what commands e2scrub_all would execute.
-r: Remove e2scrub snapshots.
-A: Scrub all ext[234] filesystems even if not mounted.
-V: Print version information and exit.
When manual pages exist they're wonderful and lovely. It's a good standard, and my favorite is when the online help system of a given script or installed package (e.g. via pip) emulates man--but there aren't always man pages
that's the entire point of my complaint here. It's unreliable in many contexts, but you do always have access to the command itself.
Never heard of echo? What do you expect this to do?
echo --help $ echo --help
--help
$ type echo
echo is a shell builtin Usage: /usr/bin/echo [SHORT-OPTION]... [STRING]...
or: /usr/bin/echo LONG-OPTION
Echo the STRING(s) to standard output.
-n do not output the trailing newline
etc.
NAME
echo - echo arguments
SYNOPSIS
echo [ arg ... ]
DESCRIPTION
Echo writes its arguments in order as a line on the standard
output file. It is mainly useful for producing diagnostics
in command files.Letting me know that the proper way to ask for help is `-help` also communicates that GNU style double dash long opts is not the way to go with this particular program.
Then I suppose you could argue that GNU style double dash options should be supported. Meh, I dunno. They were the ones that invented the fifteenth standard (xkcd/927).
I don't care at all which type the program likes. I just can't remember which programs like which styles. So I ask them. And I prefer if they don't insult me when I do.
I just don't really see how that one, single, extra three second step is much to get upset about, and I think it's just welcome that it rubs me in the face that I got it wrong. It makes me not gloss over the help text and start double dashing my way into the next to command.
But sure, I see your point. I just wished K&R had had the forethought to establish a proper standard. I don't particularly care what it would have been.