On 5/1/2019 3:03 PM, Viktors Berstis wrote:
> When running "ls" or "ls -U" on a windows directory containing 5
> files, ls takes forever. Something seems to be highly inefficient in there.
>
---
it sounds like you are running ls with no options
(nothing in environment and no switches o
Hi
Although this bug report seems to be a problem with the windows port
of ls, it reminded me of an interesting investigation into slow ls
speeds due to colorizing via the LS_COLORS environment variable.
See
https://news.sherlock.stanford.edu/posts/when-setting-an-environment-variable-gives-you
On Friday, May 3, 2019 5:56:35 PM CEST Viktors Berstis wrote:
> I don't think the problem has anything to do with sorting or -U1.
It was unclear what you meant by "the problem" so I pointed out the only
inefficiency that was immediately obvious to me.
> When ls is taking over 5 minutes for s
On 5/2/19 8:43 PM, 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 " which is what I
> did.
Whoever built it just copied that line from upstream. If the build has
MS-Wind
I don't think the problem has anything to do with sorting or -U1. When
ls is taking over 5 minutes for something that should run in a couple
of seconds, the task manager shows that it is using nearly no CPU
it is doing a lot of "other I/O".
It doesn't look like the build you re
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 "
> which is what I did. The build is so old that I suspect none of the
> original pla
