* Possible bug in zargs @ 2012-10-27 22:34 Dima Kogan 2012-10-30 7:05 ` Dima Kogan 0 siblings, 1 reply; 4+ messages in thread From: Dima Kogan @ 2012-10-27 22:34 UTC (permalink / raw) To: zsh-workers I can't seem to get the -n option in zargs to work right. This looks like a bug to me, but maybe I'm not using it correctly: dima@shorty:/tmp$ ls -l total 12 -rw-r--r-- 1 dima dima 1 Oct 27 15:29 1 -rw-r--r-- 1 dima dima 5 Oct 27 15:29 2 -rw-r--r-- 1 dima dima 5 Oct 27 15:29 3 dima@shorty:/tmp$ zargs -- * -- ls -l -rw-r--r-- 1 dima dima 1 Oct 27 15:29 1 -rw-r--r-- 1 dima dima 5 Oct 27 15:29 2 -rw-r--r-- 1 dima dima 5 Oct 27 15:29 3 dima@shorty:/tmp$ zargs -- * -- ls 1 2 3 dima@shorty:/tmp$ zargs -n1 -- * -- ls 1 2 3 dima@shorty:/tmp$ zargs -n1 -- * -- ls -l zargs: argument list too long The "argument list too long" doesn't make sense here. Thanks ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible bug in zargs 2012-10-27 22:34 Possible bug in zargs Dima Kogan @ 2012-10-30 7:05 ` Dima Kogan 2012-10-30 16:09 ` Bart Schaefer 0 siblings, 1 reply; 4+ messages in thread From: Dima Kogan @ 2012-10-30 7:05 UTC (permalink / raw) To: zsh-workers [-- Attachment #1: Type: text/plain, Size: 962 bytes --] > On Sat, 27 Oct 2012 15:34:00 -0700 > Dima Kogan <zsh@dima.secretsauce.net> wrote: > > I can't seem to get the -n option in zargs to work right. This looks like a bug > to me, but maybe I'm not using it correctly: > > dima@shorty:/tmp$ ls -l > total 12 > -rw-r--r-- 1 dima dima 1 Oct 27 15:29 1 > -rw-r--r-- 1 dima dima 5 Oct 27 15:29 2 > -rw-r--r-- 1 dima dima 5 Oct 27 15:29 3 > > > dima@shorty:/tmp$ zargs -- * -- ls -l > -rw-r--r-- 1 dima dima 1 Oct 27 15:29 1 > -rw-r--r-- 1 dima dima 5 Oct 27 15:29 2 > -rw-r--r-- 1 dima dima 5 Oct 27 15:29 3 > > dima@shorty:/tmp$ zargs -- * -- ls > 1 2 3 > > dima@shorty:/tmp$ zargs -n1 -- * -- ls > 1 > 2 > 3 > > dima@shorty:/tmp$ zargs -n1 -- * -- ls -l > zargs: argument list too long 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? [-- Attachment #2: 0001-n-option-of-zargs-now-works-correctly.patch --] [-- Type: text/x-patch, Size: 994 bytes --] >From b2d0722f78ce1c8effd69119b989a9112cbf5d27 Mon Sep 17 00:00:00 2001 From: Dima Kogan <dima@secretsauce.net> Date: Tue, 30 Oct 2012 00:02:45 -0700 Subject: [PATCH] -n option of zargs now works correctly Before this patch, the following wouls happen: dima@shorty:/tmp$ ls 1 2 3 dima@shorty:/tmp$ zargs -n1 -- * -- ls -l zargs: argument list too long --- Functions/Misc/zargs | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/Functions/Misc/zargs b/Functions/Misc/zargs index 71fd428..59b369e 100644 --- a/Functions/Misc/zargs +++ b/Functions/Misc/zargs @@ -212,20 +212,13 @@ then fi fi -n=${${n##-(n|-max-args(=|))}:-$[ARGC+c]} +n=${${n##-(n|-max-args(=|))}:-$[ARGC]} if (( n <= 0 )) then print -u2 'zargs: value for max-args must be >= 1' return 1 fi -if (( n > c )) -then (( n -= c )) -else - print -u2 zargs: argument list too long - return 1 -fi - s=${${s##-(s|-max-chars(=|))}:-20480} if (( s <= 0 )) then -- 1.7.10.4 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible bug in zargs 2012-10-30 7:05 ` Dima Kogan @ 2012-10-30 16:09 ` Bart Schaefer 2012-10-30 17:53 ` Dima Kogan 0 siblings, 1 reply; 4+ messages in thread From: Bart Schaefer @ 2012-10-30 16:09 UTC (permalink / raw) To: Dima Kogan, zsh-workers 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'. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible bug in zargs 2012-10-30 16:09 ` Bart Schaefer @ 2012-10-30 17:53 ` Dima Kogan 0 siblings, 0 replies; 4+ messages in thread From: Dima Kogan @ 2012-10-30 17:53 UTC (permalink / raw) Cc: zsh-workers > On Tue, 30 Oct 2012 09:09:09 -0700 > Bart Schaefer <schaefer@brasslantern.com> wrote: > > 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'. > Thanks, Bart. I indeed missed that part of the doc. Sorry for the false alarm. dima ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-10-30 18:00 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-10-27 22:34 Possible bug in zargs Dima Kogan 2012-10-30 7:05 ` Dima Kogan 2012-10-30 16:09 ` Bart Schaefer 2012-10-30 17:53 ` Dima Kogan
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).