On 11/7/23 07:10, Ronan Pigott wrote:
Hey find users,I have a question about the behavior of GNU find. Consider the following invocation of find $ find one/ two/ -name file one/file two/file I want to know if there exists directories one/ and two/ and a matching file in each directory, is the above output guaranteed in the given order? Does find always print all the matches below the first starting point argument before any matches below the following starting point argument and so on?
This is an interesting question. First of all, the POSIX specification is silent about whether the given paths shall be processed in the given order or not. The man page of GNU find(1) is quite clear about the order (right at the top of the page): https://git.savannah.gnu.org/cgit/findutils.git/tree/find/find.1?id=9a6b5821#n13 GNU find searches the directory tree rooted at each given starting-point by evaluating the given expression from left to right, [...] Also the Texinfo manual states the same, see `info '(find)Starting points'`, or: https://git.savannah.gnu.org/cgit/findutils.git/tree/doc/find.texi?id=9a6b5821#n359 https://www.gnu.org/software/findutils/manual/html_node/find_html/Starting-points.html#Starting-points
With a glance at the code, it seems this does describe the current behavior of GNU find since it process each arg in order (please correct me if wrong), and I think it's a somewhat useful property, but I could find no statement guaranteeing the behavior in the man page or info pages, and no related discussion on this list. Theoretically there might exist some possible optimization on platforms like Linux with, say io_uring, which would not necessarily lend themselves quite as naturaly to the same guarantee, especially if dir one had many many more files than dir two.
From coding point of view, the current behavior is the natural order, and I would not expect any find implementation to behave differently (although POSIX would probably allow this).
Can we decide whether this is an unintended behavior or intended feature of GNU find?
As it's documented since the "initial revision" back in 1996 at least, I don't think the behavior could ever change. Therefore, I'd call it a feature. :-) FWIW: also the -files0-from option reading the starting points from the given file works in the same way, i.e., it processes each NUL-terminated entry one after each other in their given order. P.S. The order of output for files found _below_ a starting point is not defined, though. Have a nice day. Berny
