coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Determination of file lists from selected folders without returning


From: Eric Blake
Subject: Re: Determination of file lists from selected folders without returning directory names
Date: Mon, 17 Jul 2017 15:40:32 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 07/17/2017 03:25 PM, SF Markus Elfring wrote:
> Does a mapping of the function “opendir” (or “fdopendir”) exist for a command?
> 

Only indirectly, and typically via programs that (can) do recursion.
'find' is your best bet (it does not sort; while ls does, so find is
inherently going to visit files faster than ls); couple find with a
-maxdepth 1 so that it doesn't recurse by default, and the only thing
faster is then shell expansion of globs (as in 'echo *').

> Can a similar feature request “Determination of a file list from a single 
> folder
> without changing the working directory” (for the tool “GNU Make”) help for
> a better understanding?
> https://savannah.gnu.org/bugs/index.php?51309

Yes, that helps immensely for framing the problem you are trying to
solve.  'echo "echo $(ls *txt)"' is inherently slower (and at more risk
of bugs due to \n in file names, etc) than 'echo *.txt'.

> 
> 
>> $ find a -maxdepth 1 \! -type d -printf %f\\n
> 
> Can it be that this command retrieved more data than necessary just for the
> display of the basename?

strace it and find out, or read the source (this is open source, after
all).  But my gut feel is that no, it's pretty well optimized already
for a minimum of syscalls, particularly for filesystems that report file
types through readdir() (thus avoiding the need for secondary stat()
calls).  Optimizing find may be better discussed on the findutils list,
though.  For a directory with enough contents, it might even be that the
GNU find invocation outperforms a comparable $(cd dir && echo *txt),
because it avoids userspace globbing overhead, although I did not try to
benchmark that to confirm things.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]