Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
zargs error with some combinations of arguments
- X-seq: zsh-workers 50486
- From: Alan Wagner-Krankel <awk@xxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: zargs error with some combinations of arguments
- Date: Thu, 18 Aug 2022 21:06:16 -0500
- Archived-at: <https://zsh.org/workers/50486>
- List-id: <zsh-workers.zsh.org>
I've run across some conditions that apparently trip up calls to
zargs. A simplified example:
zsh -f <<\eof
vals=(${(l:79::x:):-{001..256}})
print count:${#vals} length:${(c)#vals}
autoload -Uz zargs
zargs -- $vals -- print -l
eof
The output:
count:256 length:20479
zargs: cannot fit single argument within size limit
This error occurs when:
- the combined length of the arguments that are going to be used in a
call is less than the max argument size (-s, default is 20480), and
- the length of the command string plus the arguments is greater than
the -s size value.
It looks like zargs was set up this way to emulate the behavior of
gxargs from GNU findutils. With the right options, you can get a
similar error:
gxargs -L 256 -s 20480 -x echo <<<${(f)${(l:79::x:):-{001..256}}}
On my system this returns:
gxargs: argument list too long
I wasn't able to find an input that gave this result when using
the (large) defaults for gxargs.
On the other hand, POSIX seems to want the constructed command to fit
within all of the various size arguments, if I'm reading this snippet
in the spec correctly:
-s size
Invoke utility using as many standard input arguments as possible
yielding a command line length less than size (a positive decimal
integer) bytes. Fewer arguments shall be used if:
- The total number of arguments exceeds that specified by the -n
option.
- The total number of lines exceeds that specified by the -L option.
I've run into the zargs error a couple of times recently with
real-world data, so my system is now using a version that is hopefully
a bit closer to the POSIX behavior. The diff listing is below.
Another option would have been to use a large value for -s, and
significantly reduce the likelihood of hitting a set of inputs that
result in an error. That seems to be the gxargs approach.
Any thoughts? Is there something else I missed, or is a change like
I've described something that you want to consider for a future
version of zargs?
Thank you for reading this far. Hope I didn't make too many mistakes
in my first post to the list :).
Thanks,
Awk
diff --context=1 zsh.5.9/Functions/Misc/zargs ~/.zfunctions/zargs
*** zsh.5.9/Functions/Misc/zargs
--- ~/.zfunctions/zargs
***************
*** 178,180 ****
! local -i end c=0
if [[ $eof == -(e|-eof) ]]; then ((end=ARGC+1))
--- 178,180 ----
! local -i end a c=0
if [[ $eof == -(e|-eof) ]]; then ((end=ARGC+1))
***************
*** 249,250 ****
--- 249,257 ----
+ (( a = s - ${#:-"$command "} ))
+ if (( a <= 0 ))
+ then
+ print -u2 'zargs: value for max-chars must be >= command length'
+ return 1
+ fi
+
l=${${${l##*-(l|L|-max-lines(=|))}[-1]}:-${${l[1]:+1}:-$ARGC}}
***************
*** 291,293 ****
((ARGC)) || break
! for (( end=l; end && ${(c)#argv[1,end]} > s; end/=2 )) { }
(( end > n && ( end = n ) ))
--- 298,300 ----
((ARGC)) || break
! for (( end=l; end && ${(c)#argv[1,end]} > a; end/=2 )) { }
(( end > n && ( end = n ) ))
Messages sorted by:
Reverse Date,
Date,
Thread,
Author