walking a directory with very many files

[Lie Ryan]

Lawrence D'Oliveiro wrote:
> In message <pan.2009.06.24.02.20.10 at REMOVE.THIS.cybersource.com.au>, Steven 
> D'Aprano wrote:
> 
>> On Tue, 23 Jun 2009 10:29:21 -0400, Mel wrote:
>>
>>> Steven D'Aprano wrote:
>>>
>>>> Lawrence D'Oliveiro wrote:
>>>>
>>>>>> Ok, now pipe ls to less, take three days to browse through all the
>>>>>> filenames to locate the file you want to see.
>>>>> Sounds like you're approaching the issue with a GUI-centric mentality,
>>>>> which is completely hopeless at dealing with this sort of situation.
>>>> Piping the output of ls to less is a GUI-centric mentality?
>>> Yeah.  The "dump it on the user" idea, or more politely "can't decide
>>> anything until the user has seen everything" is evident in the most
>>> "characteristic" GUIs.
>> Perhaps you're using different GUIs to me. In my experience, most GUIs
>> tend to *hide* data from the user rather than give them everything under
>> the sun.
> 
> Which is getting a bit away from what we're discussing here, but certainly 
> it is characteristic of GUIs to show you all 400,000 files in a directory, 
> or at least try to do so, and either hang for half an hour or run out of 
> memory and crash, rather than give you some intelligent way of prefiltering 
> the file display up front.

In many debugging cases, you don't even know what to filter, which is
what I was referring to when I said "Even with glob and grep ..."

For example, when the problem mysteriously disappears when the file is
isolated