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:

    (for cmd in /usr/bin/*; do echo "CMD: $cmd"; "$cmd" -h; done) >/tmp/dash-h 2>&1
    (for cmd in /usr/bin/*; do echo "CMD: $cmd"; "$cmd" --help; done) >/tmp/dashdash-help 2>&1

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

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