Open GoogleCodeExporter opened 9 years ago
This is expected behaviour, and even if it takes a long time, you can still
type in
and run other commands - the shell does not block while commands are running.
But maybe there should be a check for the number of files, and if there are too
many
files, a simple count of files could be returned.
In addition a flag (for cd) to suppress the ls of files might be useful.
Original comment by dmi...@gmail.com
on 13 May 2008 at 3:49
See the screenshot to get the idea of the number of files it found. Sticking
that to
a List View results in bringing the system to its knees.
Why would having cd do ls be considered expected behaviour? There is an
explicit ls
command for that.
Original comment by pat...@gmail.com
on 13 May 2008 at 3:55
Yeah, I think for this kind of thing it would make sense to cut off display
after a
certain number or percentage, with notification that there are more not shown.
How to determine that number is a bit tricky; perhaps a percentage of total
memory?
Try to measure how many we can process per second?
Original comment by cgwalt...@gmail.com
on 16 May 2008 at 11:39
How about setting a hard timeout to say 1 second? It would still get in the way
but
would allow me to type without waiting for the letters to appear one at a time
;)
Original comment by pat...@gmail.com
on 17 May 2008 at 12:01
Experimenting on my system (using
ls /usr/bin/ | head -500
and other values in head) 500 starts to have a noticeable delay, but isn't too
bad.
So I guess we need (command line and environment) options to change that limit,
maybe
with 0 being unlimited.
Original comment by dmi...@gmail.com
on 17 May 2008 at 4:13
I sympathize with the reporter - I mostly find auto-ls too slow to be useful as
well.
I would make it a config option at least and maybe even default to off.
Original comment by juhpeter...@gmail.com
on 31 Jul 2008 at 5:08
Original issue reported on code.google.com by
pat...@gmail.com
on 12 May 2008 at 12:52Attachments: