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!
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!