Mail Archives: djgpp/2004/10/16/18:31:05
Eli Zaretskii wrote:
>>From: "one2001boy AT yahoo DOT com" <one2001boy AT yahoo DOT com>
>>Date: Fri, 15 Oct 2004 15:58:28 GMT
>>
>>I think the algorith for ls.exe might be optimized so that it can
>>display some processed files and directory first, not wait till all
>>files are processed.
>
>
> ls.exe cannot possibly do that because it sorts the files according to
> some criterion (by default, the file name). How can it possibly sort
> the files before it has them all?
>
It is fine to sort by filename, but I think ls.exe also will check if
the file is direcotry/file/executable/ etc.
If I have three thousand files, ls.exe might need to process all of them
and then start to display. What I mean is that if ls.exe sort and then
check 100 files for directory name/file name/executable, and then
display those 100 files, and then process the rest files to check the
directory name/file name/executable. it can avoid the long waiting time.
>
>>dir can display the file and directory, "ls" cannot tell the difference
>>between file and direcotry in the display. thus, "ls -F" is preferred.
>>but it is too slow to use for directory with thousandss of files.
>
>
> If all you need is to know whether a file is a directory, then ls.exe
> is not the best tool for that. Use test.exe from Sh-utils, or
> find.exe from Findutils. They are much faster for this kind of job.
I want to display all files and subdirectories in a directory, not only
one file or one subdirectory in a directory.
Thus, I have to use ls.exe -F, or dir. But ls.exe -f won't be a solution
if the directory has 2000 or 3000 files.
- Raw text -