[Toybox] toybox - added cmp

[Frank Bergmann]

Hi Rob,

On Tue, Feb 14, 2012 at 09:01:34AM -0600, Rob Landley wrote:
> Please read what I wrote.

I've already done it but I also read xargs(1) which has a statement which
doesn't make any sense in the context of the explanations. But please read
on.

> I'm explaining _why_ xargs must close the descriptor, due to exactly the
> limitation I was explaining.  It would be _useful_ to have -E delimit
> input between command line options and child stdin, but turns out to be
> difficult enough to implement that the standard allows but does not
> require it.
> 
> This is not the only place this comes up, it's just one I hit recently
> when I was implementing xargs, so it was fresh in my mind.

OK, I got it. Now I understand what you're thinking about but it sounds
crazy to me. :-)

I mentioned xargs(1). It says
"If the end of file string occurs as a line of input, the rest of the
input is ignored."
(GNU findutils).
But this is only a man-page and it is a GNU man-page which describes the
behavior of a GNU utility. ;-)

I read the standard at http://pubs.opengroup.org/onlinepubs/009695399 but
I didn't find a comparable statement.
On http://pubs.opengroup.org/onlinepubs/009695399/utilities/xargs.html I
only found this statement:
"This sequence shall be repeated until one of the following occurs: [...]
The logical end-of-file string (see the -E eofstr option) is found on
standard input [...]"
With "sequence" the genereation of command lines (fork/clone + exec) due
to the STDIN of *xargs* is meant. On this page is no statement which says
that the STDIN of xargs must be handled in a special way after eofstr is
received.
Like
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_02
says the STDOUT shall (!?) be connected to the STDIN of the next command
in a pipe(line). In other words you could say that the STDIN of xargs
"belongs" to xargs.
On other pages of this standard (e.g. head) you will find the word "copy":
"copy [...] input [...] to the standard output". This is also missing on
xargs page.
A behavior like you mean is not described on these pages of the standard.
There is no statement that xargs SHOULD behave like you described and no
statement that it MAY behave like this.

My interpretation (sigh... standards should prevent interpretations) is
that "connecting" the rest of STDIN (after eofstr) to the command(s)
xargs executes will break the standard.
IMHO it MAY be legal to read after eofstr til the end of STDIN to avoid a
sigpipe but I'm even unsure about that.

(er... wrong URLs... I just discovered "Issue 6" on the standard pages I
read, but Issue 7 only adds one line on xargs:
"All arguments up to but not including the argument consisting of just the
logical end-of-file string shall be used as arguments in constructed
command lines.")

> > (er... at this point I think about some clone options which should make
> > it possible to even share FILE* filehandles. ;-) )
> 
> You mean the way after a fork _both_ children have the buffered data and have
> to work out which one's going to use it?

Yes, IMHO this is possible with clone and specific options. But it's crazy
and just a joke. No one ever should do this. The LKML would speak a holy
curse against him. ;-)

Frank

-- 
EDV Frank Bergmann                           Tel.     05221-9249753
LPIC-3 Linux Professional                    Fax      05221-9249754
Pödinghauser Str. 5                          email    iservice at tuxad.com
32051 Herford                                USt-IdNr DE237314606

 1329292039.0