== How SuS probably requires the 'run at least once' _xargs_ behavior

A commentator left a long comment on [[my entry about how _xargs_
behaves with no input XargsZeroArgsIssue]] arguing that [[the
Single Unix Specification for _xargs_
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/xargs.html]]
actually requires it to not run if standard input is empty. I think
it's more likely to be the other way around, so today I want to run
down why I think the SuS probably requires this annoying behavior.

There are two important sections of the SuS _xargs_ specification
here and I'm going to quote both, bolding important bits:

> The *xargs* utility shall construct a command line consisting of
> the *utility* and *argument* operands specified followed by as many
> arguments read in sequence from standard input as fit in length and
> number constraints specified by the options. ~~The *xargs* utility
> shall then invoke the constructed command line and wait for its
> completion. This sequence shall be repeated until one of the following
> occurs~~:
>
> * An end-of-file condition is detected on standard input.
>
> [... other conditions elided ...]
>
> [...] The utility named by *utility* shall be executed ~~one or more
> times~~ until the end-of-file is reached or the logical end-of file
> string is found. [...]

Now we get to play the fun game of interpreting standards. The easiest
place to play this game with is the last sentence I quoted, which
says both that the *utility* shall be executed at least once and that
this happens until end-of-file is reached. If end of file is reached
immediately, which takes precedence? In the style of reading standards
that I've absorbed, explicit statements generally trump implications;
that would mean that the explicit promise that *utility* shall be
executed at least once trumps the potential implication of not running
it on immediate EOF.

The first paragraph as a whole offers a similar conflict. It is easy to
read it as a series of steps: first read in as many arguments as you can
that fit, then run the command, and only then check for exit conditions
and repeat if they are not met. You don't check for exit conditions
before you run the command once because that's not what the series
of steps tells you to do, and 'zero arguments' is not ruled out as a
valid number of arguments to read from standard input; ergo, _xargs_
runs the command line once even on immediate EOF. You can also read it
as a general description instead of a series of steps, with the 'this
sequence shall be repeated until ...' forming the framing procedure
around the specific two steps used to form and run each command line; in
this reading it's correct to run zero times if there is an immediate end
of file on standard input since the framing loop's exit condition has
been met.

If we read the first paragraph using an 'explicit trumps implicit' rule
then I think that we have to conclude that the paragraph is the set of
steps that _xargs_ is intended to follow as it executes because this is
exactly how the paragraph is written. This interpretation is reinforced
by the 'once or more' language in the later paragraph.

None of this is unambiguous; the SuS specification never comes out and
says outright '_xargs_ runs once even if it reads no arguments'. But
given how much the usual extremely legalistic, 'every word and phrase
and ordering decision counts' approach to reading standards pushes us
towards the '_xargs_ runs once on EOF' interpretation, I think it's
probably what SuS actually requires.

(Note that none of this matters in practice. As covered in [[the first
entry XargsZeroArgsIssue]], existing systems have no common behavior.
The closest you can get is to always specify _-r_ so that _xargs_ does
not run once, which works on GNU findutils, sufficiently recent FreeBSD,
and OpenBSD.)

PS: this is not the most crazy thing in the SuS _xargs_ specification.
If you care about _xargs_ portability and want to be horrified, read
the description of _-E_ carefully.

(Also, [[these crazy things are almost certainly not the fault of
the SuS authors https://twitter.com/thatcks/status/327277321784537088]].)