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

I've got a directory with about 100,000 files in it. ls -f hangs for over a minute. I ran strace, and immediately started seeing getdents, so ls is clearly reading the directory. I also see a lot of calls to brk, so ls is clearly buffering things in memory. I wrote a simple program that calls readdir and outputs filenames, and it responds immediately. But ls -f does not provide output. What gives? I thought the whole point of -f is that it causes ls to do nothing more than readdir. Is there a portable, reliable way to list the contents of a directory? (Note, this is ls from gnu's coreutils on Linux.)


There was an alias in place, but "/bin/ls -1f > /dev/null" takes 8 to 15 seconds, "/bin/ls -1fx > /dev/null" takes 4 to 11 seconds, but a simple program that just does readdir takes .011 seconds. What do I need to do to make gnu ls not suck?

share|improve this question

The point of -f is to try and avoid the need to stat every file entry, and to avoid the need to read them all before any are displayed. It is a "meta" option that just disables other options.

So, yes, it should do what you expect. I can't answer why it isn't, but I would guess that you might have a shell alias or something else that inserts additional options to the command. That might reenable a feature than -f disables, and be considered "more specific", so take precedence.

share|improve this answer
Argghh. ls() { /bin/ls -FB $@; } Stupid startup scripts. – William Pursell Feb 2 '12 at 18:19
hmm. I unset the function and I still see the same behavior even when I run /bin/ls. – William Pursell Feb 2 '12 at 18:21
Do /bin/ls -f -1 (that's minus-one, not minus-ell). The /bin/ls on a RHEL box I'm using formats file names in columns for some reason. – Bruce Ediger Feb 2 '12 at 18:39

An optimization was added in coreutils 7.0 (commit 8d974b00fbbc2025de63e1e6d54827648fefa1c4):

2008-08-01  Kamil Dudka  <kdudka@redhat.com>
    ls -U1 now uses constant memory
    When printing one name per line and not sorting, ls now uses
    constant memory per directory, no matter how many files are in
    the directory.
    * ls.c (print_dir): Print each file name immediately, when possible.
    * NEWS: Mention the improvement.

The first explanation that comes to mind is that you're running an older version of coreutils. You need to upgrade.

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.