[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



> From: Adam Cormany <acormany yahoo com>
> Subject: bash: /bin/ls: Argument list too long
> To: Redhat List <valhalla-list redhat com>
> 
> I have a directory called Pictures. Inside it is 8059
> .jpg images. If I'm sitting inside the Pictures
> directory, I can `ls -l *.jpg|wc -l` with no problem,
> but if I'm sitting outside the directory and do `ls -l
> Pictures/*.jpg|wc -l` I get "bash: /bin/ls: Argument
> list too long". I think I understand why I'm getting
> it. Basically with me adding *.jpg, the actual command
> would be ls -l file1.jpg file2.jpg file3.jpg and so
> forth, correct? I can do `ls Programs|wc` fine but I'm
> sure even that will die after more images are added to
> this directory.

Nope -- "ls Programs | wc" won't die because the argument list that
"ls" sees is just "Programs".  The resulting long list just goes
from STDOUT of "ls" to STDIN of "wc", so there's never a long argument
list.

You could also do 
   find Pictures -name '*.jpg' | wc
Note that the "*.jpg" is quoted, so it doesn't get expanded by the
shell and fed as an argument to find, but rather gets expanded by
"find" into its STDOUT string .



> My questions are:
> 1) What is the max string length for ls?

It has nothing to do with "ls", it's a kernel limit which is 128KB
in Red Hat (at least since 6.x).

> 2) Is there a way to increase the max length for ls
> arguments?

The problem with the wild card is that the shell expands "Pictures/*.jpg"
into a string that's too large to fit in the kernel's argument string
buffer.  This is a kernel parameter that's defined in
/usr/include/linux/binfmts.h to give a 128KB buffer for the argument list.
You could change it and rebuild the kernel, but it's better to learn how do
do things without generating long argument lists for a command.

> I realize I could make seperate directories and try to
> seperate some of the images to reduce the size of
> files in each directory, but I will still run into
> this problem with commands like ls and find I would
> think?

As mentioned above, "find" doesn't have a problem if used properly, you
just need to avoid having the shell expand wildcards into huge strings.  Of
course you don't want to put the "find" expression into backticks or you'd
have the same situation you had with ls and the wild card expansion.

In cases where you THINK you need to do that, you should learn about xargs.

Instead of:
        rm `find . -name '*.jpg'`
use:
        find . -name '*.jpg' | xargs rm

> Thanks in advance,
> Adam
> 

-- 
    pete peterson
    Teradyne, Inc.; 7 Technology Park Drive; Westford, MA 01886-0033
    +1-978-589-7478 (Office); +1-978-589-2088 (FAX);
    pete peterson teradyne com or petersonp genrad com

 





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]