[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #52137] unexpected behaviour when combining -I and -n

From: James Youngman
Subject: [bug #52137] unexpected behaviour when combining -I and -n
Date: Wed, 15 Nov 2017 15:05:35 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36

Follow-up Comment #8, bug #52137 (project findutils):

The approach (issue a warning without changing the current semantics of
sequences of these options) seems good to me.   I'd like to apply this patch
basically as-is, with perhaps a couple of tweaks to the wording of the NEWS
entry and the warning message; details of those tweaks below.   Also, further
below, a concern about POSIX conformance.

The NEWS file mentions the options by long form, while I think that since
these options are POSIX-specified, it's very likely that most uses of these
options will be via the single-letter form.   So IMO we should provide the
short-form options in the NEWS - either instead, or as well.

On the other hand, some users may indeed use long options.   However, when
we're processing options and find that "exclusive" options have been given, we
(with this patch) issue a message which gives only the short form.   This
could be confusing if the user actually specified the long form of the

I notice that there have also been changes between the 2004 (Issue 6,
http://pubs.opengroup.org/onlinepubs/009604599/utilities/xargs.html) and the
(Issue 7,
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/xargs.html) POSIX

In issue 6, -L and -n are specified to interact such that the last-specified
takes effect.  The -I option is specified, but no interaction with -L or -n is
called out.

In issue 7, we have the previously quoted phrase:

"The -I, -L, and -n options are mutually-exclusive. Some implementations use
the last one specified if more than one is given on a command line; other
implementations treat combinations of the options in different ways."

However, this quote is taken from the Rationale section which is non-normative
(per the comment earlier in the document, "The following sections are

Since the text stating that these options are mutually exclusive is
non-normative, and that the text doesn't seem to indicate that  the user
should expect anything other than a perhaps-unexpected combination of
behaviours, I'm left not totally sure that the xargs implementation is allowed
to issue a diagnostic.  

Geoff, do you have an opinion on whether a diagnostic is permissible?   If we
do issue a diagnostic, but all invocations of the named utility return 0, is
it still conforming for xargs also to return 0?


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]