From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20979 invoked by alias); 30 Oct 2012 16:09:38 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 30769 Received: (qmail 2589 invoked from network); 30 Oct 2012 16:09:35 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <121030090909.ZM7599@torch.brasslantern.com> Date: Tue, 30 Oct 2012 09:09:09 -0700 In-reply-to: <20121030000536.260d4c15@shorty.local> Comments: In reply to Dima Kogan "Re: Possible bug in zargs" (Oct 30, 12:05am) References: <20121027153400.77571174@shorty.local> <20121030000536.260d4c15@shorty.local> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Dima Kogan , zsh-workers@zsh.org Subject: Re: Possible bug in zargs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Oct 30, 12:05am, Dima Kogan wrote: } } Attached is a patch that fixes this. There was some misbehaving logic } in the script. I don't understand why that logic was ever necessary. } Does anybody know why the value of $n was connected to the value of $c } at all? Sorry, meant to reply to this thread earlier but I had an unusually busy weekend. Short answer: The previous behavior was the intended behavior and I'm going to recommend against accepting this patch. $n represents the maximum number of arguments that may be passed to the called command. NOT the maximum number of arguments that may be taken from the input list and added to the other arguments of the command, but the maximum that may be passed to the command, period. $c is the number of arguments of the command that appear outside of the input list, that is, the number of arguments that trail the end of the whole zargs construct. In your example: } > dima@shorty:/tmp$ zargs -n1 -- * -- ls -l } > zargs: argument list too long You've said that "ls" should be passed at most one argument (-n1). That one argument is "-l". Therefore there is no room to pass any of the arguments from the input list (expansion of "*") without passing too many arguments, so you get the error. This may seem silly your example above, but it could be very important if for example you're using a larger value of -n with some sort of $(command) substitution generating the command for zargs to execute. What you actually want in your example is this: zargs -l1 -- * -- ls -l The manual page explains this: The options -i, -I, -l, -L, and -n differ slightly from their usage in xargs. There are no input lines for zargs to count, so -l and -L count through the INPUT list, and -n counts the number of arguments passed to each execution of COMMAND, _including_ any ARG list. Also, any time -i or -I is used, each INPUT is processed separately as if by `-L 1'.