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
signature.asc
Description: OpenPGP digital signature
