First of all, in standard getopt()
-style argument processing, arguments don't have to be squished against the option they apply to, they just can be. So if -f
takes an argument, both of the following are valid:
command -ffoo positional arguments
command -f foo positional arguments
What you call the "second interpretation" is in fact very, very rare. As far as I can think of right now, tar
and mt
are the only extant commands that works that way... and, as you mention, jar
, but that's only because it emulates tar
. These commands process arguments very differently from the standard getopt()
-style. The options are not even preceeded by -
! I can't say for sure why it was rarely used, but I would guess that it's because of the fact that it's harder to tell what options go with what arguments. For example, if b
and d
take arguments but a
, c
, and e
don't, then you have this:
command abcde b-argument d-argument
...which means that while you are composing the command you have to look back at the option letter group, read it again, remember which options you specified require arguments, and write out the arguments in the same order. What about this?
command adcbe b-argument d-argument
Oops, the d
option got the b-argument
and vice versa. Worse, if you see:
command lmnop foo bar baz
...and you are not familiar with the command, you have no idea which arguments go with which options. foo
, bar
, and baz
might be arguments to n
, o
, p
(and l
and m
take no arguments) or foo
and bar
might go with, say m
and p
while baz
is a positional parameter... or many other possible combinations.
(As this does not answer the question, this is should have been a comment, but is too long - so treat it as a comment).
As an alternative to FreeBSD's xargs you can use GNU Parallel which does not have this limitation. It even supports repeating the context:
seq 10 | parallel -Xj1 echo con{}text
seq 10 | parallel -mj1 echo con{}text
GNU Parallel is a general parallelizer and makes is easy to run jobs in parallel on the same machine or on multiple machines you have ssh access to. It can often replace a for
loop.
If you have 32 different jobs you want to run on 4 CPUs, a straight forward way to parallelize is to run 8 jobs on each CPU:
GNU Parallel instead spawns a new process when one finishes - keeping the CPUs active and thus saving time:
Installation
If GNU Parallel is not packaged for your distribution, you can do a personal installation, which does not require root access. It can be done in 10 seconds by doing this:
(wget -O - pi.dk/3 || curl pi.dk/3/ || fetch -o - http://pi.dk/3) | bash
For other installation options see http://git.savannah.gnu.org/cgit/parallel.git/tree/README
Learn more
See more examples: http://www.gnu.org/software/parallel/man.html
Watch the intro videos: https://www.youtube.com/playlist?list=PL284C9FF2488BC6D1
Walk through the tutorial: http://www.gnu.org/software/parallel/parallel_tutorial.html
Sign up for the email list to get support: https://lists.gnu.org/mailman/listinfo/parallel
Best Answer
muru is right, if you check
findutil
changelog @line 1645There's an explanation in the
man
page too, see the-l
option:The -l option is deprecated since the POSIX standard specifies -L instead.
and also further down: