"Argument list too long" (E2BIG) and the ARG_MAX limit

What it is

Argument list too long is the shell's rendering of E2BIG, which execve(2) returns when the combined size of the argument list and environment for a new program exceeds the kernel's limit, generally called ARG_MAX. The manual page for execve(2) documents that this accounting includes the environment as well as the arguments, so a large exported environment leaves less room for arguments before the same limit is hit; since Linux 2.6.23 the total is a quarter of the stack size limit (ulimit -s), and any single argument or environment string longer than 128 KiB fails with the same error even when the total is small. The usual trigger is shell globbing: a command like rm /path/*.log where the shell expands the glob to thousands of filenames before execve is ever called, so the failure happens before rm runs at all.

Why it matters

The failure looks like a bug in the command being run, but the command never receives control: the shell's own expansion already exceeded the limit, so no amount of changing quoting or escaping inside the command line helps.

How to apply

• Diagnose: getconf ARG_MAX prints the effective limit in bytes for the current system. echo * | wc -c in the problem directory shows how large the actual expansion is, to confirm that is really what is being hit; GNU xargs --show-limits </dev/null prints the usable size after the environment.
• Fixes, least to most invasive:
  1. Batch the operation through xargs, documented as splitting a long input into as many invocations as needed to stay under the limit: printf '%s\n' *.log | xargs rm --, or, for filenames that may contain unusual characters, find . -maxdepth 1 -type f -name '*.log' -print0 | xargs -0 rm -- (without -maxdepth 1, find also descends into subdirectories and deletes more than the glob would have).
  2. Prefer find ... -exec cmd {} + over -exec cmd {} \;; the find(1) manual page documents the + form as batching as many matched names as fit into a single invocation, avoiding a separate xargs pipeline.
  3. If a bloated exported environment is eating into the same budget, reduce it before invoking the command.
  4. Restructure the task to avoid one huge argument list altogether — iterate over paths read from a file or stdin, or let the tool act on the matches itself (for deletion, find . -maxdepth 1 -type f -name '*.log' -delete) instead of listing every path on one command line.
• Not a fix: adding more quoting. The limit is on total bytes and argument count after shell expansion; how the arguments are quoted does not change that total.

Pitfalls

• Assuming a wildcard that "always worked" is safe; the same command fails once the directory grows past the threshold.
• Forgetting -print0/-0 when filenames can contain spaces or newlines, which turns a length fix into a correctness bug.