It is underappreciated that every single command-line option parser/toolkit is its own full configuration language with individual tools being "programs/configs" in that language. The lexical similarity of the zillion dialects (mostly due to Unix shells doing the word splitting for the eventual argv to be interpreted) masks what is really a dizzying diversity that for whatever reasons people think is much more uniform than it really is.
For example, I've done experiments running every single program in /usr/bin with --help and -h. The number of failures to get any useful help are a huge percentage. (The normalization of said percentage naturally is idiosyncratic to the exact system I ran that on).
Anyway, adding types to a complex one like ffmpeg may help more people realize this as well as offering practical benefits. So, great job!
I know it's not the point you were trying to make but I find "man foo" to be more reliable and useful than "foo --help" or "foo -h"
Fair enough. Finding documentation on the language is often step 1. :-) There are also giant POSIX PDFs around these days.
Also, I should have been more clear that while the CL parser toolkits are basically CfLangs/PLangs (maybe without loops, etc.), every command doing its own hand-rolled argv parser is basically its own totally unique language, probably doing only a subset of the 6..10 common conventions. It's probably not a great language, just something serviceable.
Basically, getopt wasn't good enough or easy enough or taught well enough, or done "soon enough". By the time it had come along, even within Bell Labs, they had probably grandfathered in old commands like `dd` and `find` (because "hey, I have a whopping 5 scripts that work with the old way!") with all their many & varied bespoke syntaxes.
Anyway, sadly, we only get our one try at "history" and many things are "sticky".
It was even worse on DOS; wildcard expansion happened in the program, not in the shell, so you didn't know if wildcard expansion was supported for an individual command!
You still don't know if a Unix command would support processing multiple files even if the shell would expand wildcards. The tool might still process a single file and quit.
Another issue is that, around the same time getopt was appearing, the Bourne family of shells added `key1=val1 key2=val2 mycmd` syntax, accessed more simply with either `getenv("key1")`, etc. in a C program or simply `${key1-default1}` in a script, or in python `import os; E=os.environ.get; E("key1","default1")`. This is very lightweight on the mycmd impl as it can just start using the parameter wherever, possibly with string -> native value conversion, if needed.
So, though "shell specific" (right at a time when that started to mean anything), BOTH filename pattern matching aidenn0 mentions AND "long options of a sort" were built-in at the shell level on Unix. E.g., `help= mycmd` instead of `mycmd --help`. The inheritance of environment across fork/exec made these propagate which is both blessing (propagates through wrappers, so need not capture/repeat) and curse (have to worry about namespacing/re-use).
Basically, various timing effects had outsized influence - Unix & shell diversity and right around the time GNU introduced `mycmd --key[= ]value` combined with portability agendas, and possibly syntax/properties led to long options winning. The value proposition was "Use 'cmd --key=value', not 'key=value cmd' and users with any shell will have easy syntax". I dunno..It's also hard to attribute winning.
Today, for good or ill, most people seem to literally be unaware of `key=val mycmd` calling syntax even though for bash/POSIX "beat" the C shell/most things decades ago, around when bash added the better !! history and command-line editing that made tcsh popular because mistakes happen/etc. I believe the fish shell also dropped this syntax, though.
Never heard of that syntax but it falls short on several fronts like unnamed or not-needed-to-be-named parameters. It's very easy to be confused by existence or lack of spaces in "help= cmd" too; am I assigning a variable or running a command? Not to mention that if you have an environment variable that clashes with an argument, it can have catastrophic results. I'm glad that it hasn't caught on.
On a similar note, I remember CP/M 3.0 had square bracket syntax for options like `DIR [WIDE] [ATTR=ANY]`. I think that one was probably the most intuitive one, although may not be the easiest to type. But DOS had already caught on with forward slash parameter prefixes which it also got from pre-bracket CP/M.
I think you may misunderstand - the idea is "in addition to", not "instead of" the usual syntax, `a=123 b=456 mycmd arg1 arg2 arg3 ..`, but it happens to provide a way to give "long names".
Also, it did catch on in the sense of being available, if not well known as much as POSIX (BSDs) /Bash (Linux) / Zsh (Mac OSX) caught on.
The spacing is as confusing or not as any Unix shell quoting, as in `a="1 2 3" b="4 5 6" mycmd "arg 1" "arg 2"`.
FWIW, I agree `help= cmd` looks a bit funny, though a user could probably also say, in the interests of clarity, `help=1 cmd` or `help='' cmd` if the convention was to ignore the value of `$help` and just go by its existence.
cmd [key1] arg1 [key2=val2] arg2 is interesting. Thanks for that!
For the unitiated where was the conflict?
I'm not sure I understand your question. Are you asking for a list of the hundreds of commands which did nothing useful when run as cmd -h or cmd --help? I didn't save that, and as mentioned, it'd probably be different on your own systems/with your own packages.
If you want to try this at home, you should maybe either have GOOD BACKUPS HANDY OR DO IT WITHIN A VIRTUAL MACHINE/CONTAINER (EDIT: and almost certainly NOT AS SUPERUSER) also be ready to kill processes that are hanging waiting on stdin or somesuch. You're likely to have a least a few.
WITH THIS WARNING BEING GIVEN, you could just:
Of course, you could try /bin if that's any different (for me it's a symlink to the same dir as /usr/bin these days). You could also do single dash help.If you want to accumulate some stats yourself, then you'll probably want to postprocess those output files.. So, you might also adapt the embedded echos to make it easy for whatever you like to do for that. Or, alternatively, you could re-direct each output to a per-command file with a little ${cmd##} massaging.
EDIT: and if you're asking what the CL syntax conflict was, well, I only meant to refer to "How to get any help at all - command with no args, with -h, -help, --help, -?, etc." as that is kind of the "very first question" on a user's mind. There are other syntactic conflicts (combining bool flags, option-value separation, unique prefix matching, etc., etc.).