GNU bug report logs - #35531
problem with ls in coreutils

Previous Next

Full log

Message #29 received at 35531 <at> debbugs.gnu.org (full text, mbox):

From: Kamil Dudka <kdudka <at> redhat.com>
To: Viktors Berstis <cugnujm <at> berstis.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 35531 <at> debbugs.gnu.org
Subject: Re: bug#35531: problem with ls in coreutils
Date: Fri, 03 May 2019 13:15:44 +0200

On Friday, May 3, 2019 5:43:20 AM CEST Viktors Berstis wrote:
> I downloaded it from
> https://sourceforge.net/projects/gnuwin32/files/coreutils/5.3.0/coreutils-5.
> 3.0.exe/download The help said "Report bugs to <bug-coreutils <at> gnu.org>"
> which is what I did. The build is so old that I suspect none of the
> original players are around. Do you know of a windows binary or windows
> source that is newer
> anywhere?  Thanks.
> 
> - Viktors Berstis

`ls -U1` will not run significantly faster than `ls` on powerful hardware.  
The key difference is that `ls -U1` prints the results continuously as the 
list of files is read from file system whereas `ls` will be silent until
the complete list is read.  You need to use a new enough version of coreutils 
for this to work properly.  This optimisation was introduced in coreutils-7.5:

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=v7.0~113
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=v7.5~49

Kamil

> Paul Eggert wrote:
> > On 5/2/19 5:41 PM, Viktors Berstis wrote:
> >> The newer version of "ls" built for Windows has the problem.
> > 
> > Ah, then you'll have to talk to whoever built that version, which is not
> > me (and generally speaking they don't hang out on this mailing list).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.