Brian Somers <[EMAIL PROTECTED]> writes:
> I looked at your patches and immediately thought ``these patches 
> can't be right'' as I was expecting it to deal with things such as 
>   xargs -I [] echo args are [], duplicated are []

It deals with it.  It conveniently ignores the second '[]' :-).
Seriosly though, what do you expect it to do in this case?  It can
either read some more from stdin, or use the same input it used for
the first case of '[]'.  I also can't think of a case when either one
of these would be useful.

I guess the only reason we would want this is if SUSv2 defines it, but
even that may not matter since we probably won't support the silly
'-i[nospace]' semantic (other than being silly, I can't think of how
to implement it without writing a custom getopt() facility).

> I'm also dubious about the patches working for large volumes on 
> standard input.  At this point I scrapped the email I was composing 
> 'cos I didn't have time to look into it further :-/
> I think it's important to test any patches with a large number of 
> large path names as input - so that ARG_MAX is reached before the 
> 5000 argument limit and we can see that we don't end up getting E2BIG 
> because of an accidental overflow/miscalculation.

Any advice on testing this (you did write rev. 1.9 of xargs.1, after
all)?  I created a file with 4500 words like this:


which ended up being 330 kB.  It ran the `utility' multiple times like
I expected it to.  That said, I don't know what kind of failure mode
to expect.  I.e., if the patch is wrong, should it have failed with
something like, "xargs: exec: argument list too long", or would it
just produce incorrect output (which I didn't really check for)?


                                        Dima Dorfman
                                        [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to