Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I run a command like ls */*/*/*/*.jpg, I get the error

-bash: /bin/ls: Argument list too long

I know why this happens: it is because there is a kernel limit on the amount of space for arguments to a command. The standard advice is to change the command I use, to avoid requiring so much space for arguments (e.g., use find and xargs).

What if I don't want to change the command? What if I want to keep using the same command? How can I make things "just work", without getting this error? What solutions are available?

share|improve this question
Useful reading: Bash FAQ 95. Without changing your command there's not much you can do besides recompiling to increase your argument list maximum size, or change your directory structure so that there are fewer files. – jw013 Aug 15 '12 at 23:12
@jw013 based on the linux kernel version it may be possible to increase the argument list - see unix.stackexchange.com/a/45161/8979 for details about the change in recent systems. – Ulrich Dangel Aug 16 '12 at 0:39
@UlrichDangel, Yup, it is possible! See my answer; my answer shows how to do it (on Linux, with a recent enough kernel). – D.W. Aug 16 '12 at 6:06

On Linux, the maximum amount of space for command arguments is 1/4th of the amount of available stack space. So, a solution is to increase the amount of space available for the stack.

Short version: run something like

ulimit -s 65536

Longer version: The default amount of space available for the stack is something like 8192 KB. You can see the amount of space available, as follows:

$ ulimit -s

Choose a larger number, and set the amount of space available for the stack. For instance, if you want to try allowing up to 65536 KB for the stack, run this:

$ ulimit -s 65536

You may need to play around with how large this needs to be, using trial-and-error. In many cases, this is a quick-and-dirty solution that will eliminate the need to modify the command and work out the syntax of find, xargs, etc. (though I realize there are other benefits to doing so).

I believe that this is Linux-specific. I suspect it probably won't help on any other Unix operating system (not tested).

share|improve this answer
Almost worked for me, $> ulimit -s 8192 $> getconf ARG_MAX 2097152 $> ulimit -s 65536 $> getconf ARG_MAX 16777216 Yet unfortunately still the same: "xargs: argument line too long" in-ulm.de/~mascheck/various/argmax – A.Danischewski Jun 6 at 14:21

This Linux Journal article gives 4 solutions. Only the fourth solution does not involve changing the command:

Method #4 involves manually increasing the number of pages that are allocated within the kernel for command-line arguments. If you look at the include/linux/binfmts.h file, you will find the following near the top:

 * MAX_ARG_PAGES defines the number of pages allocated for   arguments
 * and envelope for the new program. 32 should suffice, this gives
 * a maximum env+arg of 128kB w/4KB pages!
#define MAX_ARG_PAGES 32

In order to increase the amount of memory dedicated to the command-line arguments, you simply need to provide the MAX_ARG_PAGES value with a higher number. Once this edit is saved, simply recompile, install and reboot into the new kernel as you would do normally.

On my own test system I managed to solve all my problems by raising this value to 64. After extensive testing, I have not experienced a single problem since the switch. This is entirely expected since even with MAX_ARG_PAGES set to 64, the longest possible command line I could produce would only occupy 256KB of system memory--not very much by today's system hardware standards.

The advantages of Method #4 are clear. You are now able to simply run the command as you would normally, and it completes successfully. The disadvantages are equally clear. If you raise the amount of memory available to the command line beyond the amount of available system memory, you can create a D.O.S. attack on your own system and cause it to crash. On multiuser systems in particular, even a small increase can have a significant impact because every user is then allocated the additional memory. Therefore always test extensively in your own environment, as this is the safest way to determine if Method #4 is a viable option for you.

I agree that the limitation is seriously annoying.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.