«Argument list too long» (E2BIG) y el límite ARG_MAX

Qué es

Argument list too long es la forma en que la shell muestra E2BIG, el error que devuelve execve(2) cuando el tamaño combinado de la lista de argumentos y del entorno de un programa nuevo supera el límite del kernel, conocido generalmente como ARG_MAX. La página de manual de execve(2) documenta que este cálculo incluye tanto el entorno como los argumentos, de modo que un entorno exportado grande deja menos espacio para los argumentos antes de alcanzar ese mismo límite. Desde Linux 2.6.23, el total equivale a una cuarta parte del límite del tamaño de la pila (ulimit -s), y cualquier argumento o cadena de entorno individual de más de 128 KiB provoca el mismo error aunque el total sea pequeño. El desencadenante habitual es la expansión de globs en la shell: un comando como rm /path/*.log, en el que la shell expande el glob a miles de nombres de archivo antes de llamar a execve, de modo que el fallo se produce antes de que rm llegue a ejecutarse.

Por qué importa

El fallo parece un error del comando que se ejecuta, pero el comando nunca llega a tomar el control: la propia expansión de la shell ya superó el límite, así que cambiar las comillas o el escapado en la línea de comandos no sirve de nada.

Cómo aplicarlo

• Diagnóstico: getconf ARG_MAX imprime el límite efectivo en bytes del sistema actual. echo * | wc -c en el directorio problemático muestra el tamaño real de la expansión y permite confirmar que es eso lo que se está alcanzando; xargs --show-limits </dev/null (GNU) imprime el tamaño utilizable una vez descontado el entorno.
• Soluciones, de la menos a la más invasiva:
  1. Procesar la operación por lotes con xargs, que según su documentación divide una entrada larga en tantas invocaciones como haga falta para no superar el límite: printf '%s\n' *.log | xargs rm -- o, para nombres de archivo que puedan contener caracteres inusuales, find . -maxdepth 1 -type f -name '*.log' -print0 | xargs -0 rm -- (sin -maxdepth 1, find también desciende a los subdirectorios y borra más archivos de los que habría cubierto el glob).
  2. Preferir find ... -exec cmd {} + frente a -exec cmd {} \;; la página de manual de find(1) documenta que la forma con + agrupa en una sola invocación tantos nombres coincidentes como quepan, lo que evita tener que montar una tubería con xargs.
  3. Si un entorno exportado muy grande consume parte del mismo presupuesto, reducirlo antes de invocar el comando.
  4. Reestructurar la tarea para evitar por completo una lista de argumentos enorme: iterar sobre rutas leídas de un archivo o de la entrada estándar, o dejar que la propia herramienta actúe sobre las coincidencias (para borrar, find . -maxdepth 1 -type f -name '*.log' -delete) en lugar de enumerar todas las rutas en una sola línea de comandos.
• Lo que no es una solución: añadir más comillas. El límite se aplica al total de bytes y al número de argumentos después de la expansión de la shell; la forma de entrecomillar los argumentos no cambia ese total.

Trampas

• Dar por seguro un comodín que «siempre funcionó»: el mismo comando falla en cuanto el directorio crece más allá del umbral.
• Olvidar -print0/-0 cuando los nombres de archivo pueden contener espacios o saltos de línea, lo que convierte una corrección de longitud en un error de corrección del resultado.