Context for the question: According to POSIX specs, ARG_MAX is maximum length of command-line arguments to exec()
family of functions. Which lead me to believe that's actual number of arguments, however that clearly didn't work:
$ ulimit -s
8192
$ touch {1..18000}.jpg
$ rm *.jpg
$
Clearly, this works fine, despite being in length over 8192 items. According to D.W.'s answer, the 8192
is supposedly size in kB. So clearly the previous assumption was wrong.
This is where the actual question comes in: How do I figure out the amount of items that actually will get above 8192 kB limit ? In other words, what sort of computation I have to perform to ensure that *.jpg
type of glob will result into Argument list too long
error ?
Please note, this isn't a duplicate of What defines the maximum size of single command argument. I know about getconf ARG_MAX
and ulimit -s
values, that's not my question. I need to know how to generate enough arguments in size that will be above the limit. In other words, I need to find a way to get the error, not avoid it.
getconf ARG_MAX
for you? – jesse_b Jun 23 '18 at 18:032097152
. And I'm on Linux, btw – Sergiy Kolodyazhnyy Jun 23 '18 at 18:06xargs
? – Jeff Schaller Jun 23 '18 at 18:23Argument list too long
error. So far I've figured outulimit -s
gives stack space, ARG_MAX is subset to that. I see so far thatgetconf ARG_MAX
gives basically 2M by default for argument size, 8M for stack space. So basically all I need to know is how to create enough filenames to go beyond 2M limit, so that when I do*.jpg
in any command that involvesexec()
family of function would throw that error. – Sergiy Kolodyazhnyy Jun 23 '18 at 18:33ulimit -s
reports the stack size, which is unrelated to the size of the 'argument + environment' limit. – Jonathan Leffler Jun 24 '18 at 18:59ulimit -s
value changes,getconf ARG_MAX
value also changes proportionally ? – Sergiy Kolodyazhnyy Jun 24 '18 at 19:07ulimit -a
reports one line sayingstack size (kbytes, -s) 8192
, so on this system,ulimit -s
directly affects the process stack size. Referring to POSIX is no help; itsulimit
command only affects file sizes. I don't know why Linux changesARG_MAX
when the stack size changes. On a Mac, both before and afterulimit -s 2048
,getconf ARG_MAX
still reports 262,144. […continued…] – Jonathan Leffler Jun 24 '18 at 19:19<limits.h>
says: {ARG_MAX
} Maximum length of argument to the exec functions including environment data. Minimum Acceptable Value: {_POSIX_ARG_MAX
} POSIXexecve()
says: The number of bytes available for the new process' combined argument and environment lists is {ARG_MAX
}. It is implementation-defined whether null terminators, pointers, and/or any alignment bytes are included in this total. – Jonathan Leffler Jun 24 '18 at 19:19