If you have two zip files a.zip
and b.zip
in your current directory, then
$ cp *.zip destination/
expands to
$ cp a.zip b.zip destination/
The semantics for cp
is to copy both a.zip
and b.zip
to destination.
If you type
$ cp \*.zip destination/
it simply "expands" to
$ cp '*.zip' destination/
i.e. it will try to copy a single file named "*.zip" to destination, which is not what you want.
On the other hand if you type
$ unzip *.zip -d destination/
it will again expand to
$ unzip a.zip b.zip -d destination/
The semantics for unzip
is to find a file named "b.zip" inside the archive "a.zip", which is again not what you want.
If you type
$ unzip \*.zip -d destination/
the unzip
command does not simply try to unzip the file called *.zip
but it will unzip all files ending with .zip
.
The difference is that both commands interpret their arguments differently.
Best Answer
That depends greatly on the system and version, on the number and size of the arguments and on the number and size of environment variable names.
Traditionally on Unix, the limit (as reported by
getconf ARG_MAX
) was more or less on the cumulative size of:'\0'
)'\0'
), an environment string being by convention something likevar=value
.Bearing in mind that
cp
also counts as an argument (is the first argument).On Linux, it depends on the version. The behaviour there changed recently where it's not longer a fixed space.
Checking on Linux 3.11,
getconf ARG_MAX
now reports a quarter of the limit set on the stack size, or 128kiB if that's less than 512kiB).(
zsh
syntax below):That limit is on the cumulative size of the argument and environment strings and some overhead (I suspect due to alignment consideration on page boundaries). The size of the pointers is not taken into account.
Searching for the limit, I get:
The maximum cumulative size before breaking in that case is:
Now, that does not mean that you can pass 1 million empty arguments. On a 64 bit system, 1 million empty arguments make a pointer list of 8MB, which would be above my stack size of 4MiB.
(you'll noticed it's not a E2BIG error. I'm not sure at which point the process gets killed there though if it's within the
execve
system call or later).Also note (still on Linux 3.11) that the maximum size of a single argument or environment string is 128kiB, regardless of the size the stack.