Re: ls -l|head seems to look at all files in directory

[Reuben Thomas]

On Mon, 25 May 2009, Jim Meyering wrote:

> Reuben Thomas wrote:
>
> > On Mon, 25 May 2009, Jim Meyering wrote:
> >
> > > Pádraig Brady wrote:
> > >
> > > > Reuben Thomas wrote:
> > > > > On Mon, 25 May 2009, Jim Meyering wrote:
> > > > >
> > > > > > To do what he wants you have to know that ls -1U is the only
> > > > > > way to get one output entry per readdir call.
> > > > > >
> > > > > > Reuben, you want to do it like this:
> > > > > >
> > > > > >  ls -1U|head|xargs ls -l
> > > > >
> > > > > Thanks for the hint about -1, but this doesn't seem to make any
> > > > > difference: I run "ls -1U|head" in a directory with lots of files (about
> > > > > 10,000) and it pauses for a minute or so before giving me my ten lines
> > > > > of output.
> > > > >
> > > > > If I run the command again, then of course it runs almost instantly, so
> > > > > I'm not sure what use the loops are in the tests you give.
> > > >
> > > > With the ls on fedora 8 (coreutils 6.9) I see all the
> > > > redundant getdents64() calls when using strace on Jim's command above.
> > > > With the latest coreutils I do not.
> > >
> > > Right.  The change that made ls -1U more efficient was after 6.12
> > > [v6.12-113-g8d974b0]:
> >
> > Ah, I'm using 6.10. Thanks for the clarification.
>
> Argh.
> I'll try to ask for the version number next time if you try
> to reproduce with latest tools and/or report the version number ;-)

Rather as if I didn't know better I'd assume arbitrarily long command-lines 
had been possible forever, it didn't occur to me that there might be recent 
optimisations involved, unless it was to fix unintentionally-introduced 
performance bugs.

--
http://rrt.sc3d.org/ | poetry, n.  platitude made obscure