Inspired by the recent question Why does the specific sequence of options matter for tar command?, in which the asker learned why
tar -cfv test.tar *.jpg doesn't work, I'd like to ask a followup: seriously, why not?
When a command has an option
-f that requires an argument and an option
-v that doesn't, this:
cmd -fv foo
can be interpreted in 2 different ways: the
v is the argument for the
-f option and
foo is a non-option argument, or
foo is the argument for the
-f option and the
-v option is present. The first interpretation is what POSIX
getopt() does, so there are lots of commands that behave that way.
I always preferred the second interpretation. Packing all the options together (regardless of whether they take arguments) seems more useful than squishing the
foo up against the
-f to turn
-f foo into
-ffoo. But this behavior barely exists anymore. The only command I've used lately that does it is Java's
jar (which has a syntax clearly inspired by that Sun version of
tar which accepts
tar cfv tarfile ...).
Xlib has a
XrmParseCommand, which allows options to be specified as either taking "separate" args or "sticky" args. But it deals with long options (
-geometry, etc.) so it sees
-fv as just another option with no relation to either
-v. So it's not an example of my second interpretation.
When and why did squished args become dominant? Was it already settled before POSIX, or did the POSIX mandate decide the issue? Did the first version of POSIX even have the same specific requirement as the current version? Is there any archived discussion of the subject from ancient times?
Are there any other commands (besides
jar) that support or have historically supported the
-fv foo =
-f foo -v style of option parsing?