Unix administration - ls *.txt gives "bash: /bin/ls: Argument list too long" !?

This is Interesting: Free IT Magazines  
Home > Archive > Unix administration > January 2004 > ls *.txt gives "bash: /bin/ls: Argument list too long" !?





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author ls *.txt gives "bash: /bin/ls: Argument list too long" !?
Rob Baxter

2004-01-23, 5:10 pm

In issuing the following command to BASH on RH 8.0 I receive the error
"bash: /bin/ls: Argument list too long" What gives?

Command issued was:

ls *.txt

Surely there's a way around this, but the man and info pages don't
really have any information in this regard. Any help is always
apprecaited, thanks,

Rob
Bit Twister

2004-01-23, 5:10 pm

On 14 Dec 2003 15:52:15 -0800, Rob Baxter wrote:
quote:

> In issuing the following command to BASH on RH 8.0 I receive the error
> "bash: /bin/ls: Argument list too long" What gives?
>
> Command issued was:
>
> ls *.txt
>
> Surely there's a way around this, but the man and info pages don't
> really have any information in this regard. Any help is always
> apprecaited, thanks,




Today's Tip of the Day, very large
Frequently Asked Questions (faq) Search engine:

http://groups.google.com/advanced_group_search
Argument list too long in the first box
*linux* in the Newsgroup, pick English

Results 1 - 10 of about 5,080. Search took 2.02 seconds
Michael Hyman

2004-01-23, 5:10 pm

just do a 'find . -name "*.txt" -exec WHATEVER_COMMAND {} \;'

That will show you all files, or just replace the exec with ls to just see
the file names.


"Rob Baxter" <rbaxter@cyence.com> wrote in message
news:baea5fa.0312141552.f389bb5@posting.google.com...
quote:

> In issuing the following command to BASH on RH 8.0 I receive the error
> "bash: /bin/ls: Argument list too long" What gives?
>
> Command issued was:
>
> ls *.txt
>
> Surely there's a way around this, but the man and info pages don't
> really have any information in this regard. Any help is always
> apprecaited, thanks,
>
> Rob




Bill Marcum

2004-01-23, 5:10 pm

On 14 Dec 2003 15:52:15 -0800, Rob Baxter
<rbaxter@cyence.com> wrote:
quote:

> In issuing the following command to BASH on RH 8.0 I receive the error
> "bash: /bin/ls: Argument list too long" What gives?
>
> Command issued was:
>
> ls *.txt
>
> Surely there's a way around this, but the man and info pages don't
> really have any information in this regard. Any help is always
> apprecaited, thanks,
>


ls | grep '\.txt$'


--
Thanks to Nigeria, any email with the word "urgent" in the subject
or address will be deleted.
Michael Studer

2004-01-23, 5:10 pm

On Sun, 14 Dec 2003 15:52:15 -0800, Rob Baxter wrote:
quote:

> In issuing the following command to BASH on RH 8.0 I receive the error
> "bash: /bin/ls: Argument list too long" What gives?
>
> Command issued was:
>
> ls *.txt
>
> Surely there's a way around this, but the man and info pages don't
> really have any information in this regard. Any help is always
> apprecaited, thanks,
>
> Rob



Well thats interesting. Check the ls command first to see if it has been
aliased to something odd. Type "alias" by itself and see if there is a
listing for ls. Or just nuke any alias by typing "unalias ls". Then try
the command.

If no aliases exist you have found a bug. Type this:
"sh --version"
To get your version of bash. Mine is
GNU bash, version 2.05b.0(1)-release (i686-pc-linux-gnu)

Perhaps RedHat has an update for you?

I hope something in this helps you.

MS

Matias Atria

2004-01-23, 5:10 pm

Michael Studer wrote:
quote:

> On Sun, 14 Dec 2003 15:52:15 -0800, Rob Baxter wrote:
>
[...][QUOTE][color=darkred]
> Well thats interesting. Check the ls command first to see if it has been
> aliased to something odd. Type "alias" by itself and see if there is a
> listing for ls. Or just nuke any alias by typing "unalias ls". Then try
> the command.
>
> If no aliases exist you have found a bug.



It's not a bug. It's expected behavior, and precisely what xargs(1) is
meant to solve:

find . -name \*.txt | xargs ls

Cheers,
M.

Michael Studer

2004-01-23, 5:10 pm

On Tue, 16 Dec 2003 06:11:11 +0000, Matias Atria wrote:
quote:

>
> It's not a bug. It's expected behavior, and precisely what xargs(1) is
> meant to solve:
>
> find . -name \*.txt | xargs ls
>
> Cheers,
> M.



Oh really? Hmm then I must have a bug on my system.
quote:

> ls *.txt


junk.txt junk1.txt junk2.txt

MS
John Kelly

2004-01-23, 5:10 pm

Michael Studer wrote:
quote:

> On Tue, 16 Dec 2003 06:11:11 +0000, Matias Atria wrote:
>
>
>
> Oh really? Hmm then I must have a bug on my system.
>
>
>
> junk.txt junk1.txt junk2.txt
>
> MS



The original poster has a lot of .txt files and *.txt when expanded is
too long a string to fit in the command line buffer which has a finite
length. The find / xargs combination is a known way of dealing with
this situation.

So in that respect, it IS expected behaviour.

Except I never expect it when it happens to me :-)

Cheers

JK

Ian Wilson

2004-01-23, 5:10 pm

Rob Baxter wrote:
quote:

> In issuing the following command to BASH on RH 8.0 I receive the error
> "bash: /bin/ls: Argument list too long" What gives?



Your shell is performing pathname expandsion on "*.txt" and the result
is too big for the command line buffer. This is a common problem
quote:

> Command issued was:
>
> ls *.txt



It doesn't matter, any command fed *.txt unquoted(') will exhibit the
same problem.
quote:

> Surely there's a way around this,


Many ways, for example:
ls | grep '\.txt$'
find -name "*.txt" | xargs ls
su root then ls *.txt
quote:

> but the man and info pages don't
> really have any information in this regard.



You are right, the correct place for this is ...
man bash /pathname expansion
man xargs
but the man pages on RH8.0 are poor in this regard.


Doug Freyburger

2004-01-23, 5:10 pm

Michael Studer wrote:
quote:

> Matias Atria wrote:
>

Because the buffers built into shells are of finite size.
[QUOTE][color=darkred]
>
>
> Oh really? Hmm then I must have a bug on my system.
>
> ls *.txt
> junk.txt junk1.txt junk2.txt



So did you really seriously expect 3 whole filenames to blow
the internal buffers of the shell? Right, I thought not.
Chris F.A. Johnson

2004-01-23, 5:10 pm

On Wed, 17 Dec 2003 at 16:30 GMT, Doug Freyburger wrote:
quote:

> Michael Studer wrote:
>
> Because the buffers built into shells are of finite size.



It may be, but it's is more likely to be the underlying system; a
command that works on one system may fail on another. For example,
I created 9999 files ending with .x. On Linux, FreeBSD and SunOS, I
could do "echo *.x" successfully with bash and ksh (and Bourne sh
on SunOS), since echo is a built-in command.

/home/aa276/tmp $ echo *.x
0.x 1.x 10.x 100.x 1000.x 1001.x 1002.x 1003.x 1004.x 1005.x 1006.x
......
9994.x 9995.x 9996.x 9997.x 9998.x

On SunOS and Linux I could also successfully do "ls *.x", but on
FreeBSD:

$ ls *.x
-bash: /bin/ls: Argument list too long

--
Chris F.A. Johnson http://cfaj.freeshell.org
========================================
===========================
My code (if any) in this post is copyright 2003, Chris F.A. Johnson
and may be copied under the terms of the GNU General Public License
Matias Atria

2004-01-23, 5:11 pm

Doug Freyburger wrote:
quote:

>
> Because the buffers built into shells are of finite size.



It's not a shell limitation, but one of the underlying OS.
Bash has no size limit for lists, other than the amount of
memory. The problem is when you pass an extremely long list
to the execve() system call (or equivalent), which does
have fixed size limits. That's where the OP's error message
came from. See the execve(2) man page, section "ERRORS",
description of E2BIG.

Cheers,
M.

Matias Atria

2004-01-23, 5:11 pm

Ian Wilson wrote:
quote:

>
> Many ways, for example:
> ls | grep '\.txt$'
> find -name "*.txt" | xargs ls
> su root then ls *.txt



In what platform does this work for root? Definitely none
that I know of.

Cheers,
M.

Doug Freyburger

2004-01-23, 5:11 pm

Matias Atria wrote:
quote:

> Doug Freyburger wrote:
>
>
>
> It's not a shell limitation, but one of the underlying OS.
> Bash has no size limit for lists, other than the amount of
> memory. The problem is when you pass an extremely long list
> to the execve() system call (or equivalent), which does
> have fixed size limits. That's where the OP's error message
> came from. See the execve(2) man page, section "ERRORS",
> description of E2BIG.



It is both. bash may not have limited buffers but other shells
do. That is why the point where the error occurs is different
in different cases. Does the shell have a fixed buffer? How big
is that buffer on this version of Unix from this vendor at this
patch level? What is the limit on the exec* calls? What is the
virtual memory limit? Answer all of these questions, pick the
smallest number, and that's when the failure starts.

Of course answering all of those questions is too much work. It
is much easier to expect "a lot" of filenames and switch to xargs.
Use experience to build judgement about what "a lot" means.
Ian Wilson

2004-01-23, 5:11 pm

Matias Atria wrote:
quote:

> Ian Wilson wrote:
>
>
>
> In what platform does this work for root? Definitely none
> that I know of.



SCO OSR5

Matias Atria

2004-01-23, 5:11 pm

dfreybur@yahoo.com (Doug Freyburger) wrote:
quote:

> Matias Atria wrote:


quote:

[QUOTE][color=darkred]
> It is both. bash may not have limited buffers but other shells
> do.



True, but the OP is using bash on RH 8.0. That's what I had in mind.

Cheers,
M.
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com