From owner-freebsd-current Sat Apr 21 15:11: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id D947C37B423 for ; Sat, 21 Apr 2001 15:11:04 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from spike.unixfreak.org (spike [63.198.170.139]) by bazooka.unixfreak.org (Postfix) with ESMTP id 65A033E09; Sat, 21 Apr 2001 15:11:04 -0700 (PDT) To: Brian Somers Cc: Jordan Hubbard , freebsd-current@FreeBSD.ORG, olli@secnetix.de Subject: Re: cp -d dir patch for review (or 'xargs'?) In-Reply-To: <200104212116.f3LLGI549254@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on "Sat, 21 Apr 2001 22:16:18 +0100" Date: Sat, 21 Apr 2001 15:11:04 -0700 From: Dima Dorfman Message-Id: <20010421221104.65A033E09@bazooka.unixfreak.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Somers 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: /this/is/a/very/long/path/name/because/I/am/testing/some/posix/limit/10 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)? Thanks, Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message