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 option. I notice that there have also been changes between the 2004 (Issue 6, http://pubs.opengroup.org/onlinepubs/009604599/utilities/xargs.html) and the 2008 (Issue 7, http://pubs.opengroup.org/onlinepubs/9699919799/utilities/xargs.html) POSIX standards. 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 informative.") 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: <http://savannah.gnu.org/bugs/?52137> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/