On Tue, Nov 7, 2023 at 6:04 PM Bernhard Voelker <m...@bernhard-voelker.de> wrote: > > On 11/7/23 07:10, Ronan Pigott wrote: > > $ 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?
When the return value of find is zero, yes. When the return value of find is nonzero, something has gone wrong, and that might include a failure after one/file has been printed but before find has begun to process the two/ start point, or after it has processed that start point but before it has examined its child, two/file. > > 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, [...] Well, IMO it's not quite so clear. The synopsis in the manpage says: find [\-H] [\-L] [\-P] [\-D debugopts] [\-Olevel] [starting-point...\&] [expression] ... which means that the list of starting points is not part of the expression so the left-to-right expression evaluation order doesn't apply to the start points. However, as a practical matter, GNU find has always evaluated start points in the order they appear on the command line. This is left-to-right if the terminal you're using is configured for left-to-right printing and it's printing left-to-right text. I'm not familiar enough with systems configured for, say, Arabic to know whether this applies for those, too. Changing the order of evaluation or making it non-deterministic or something like that would be surprising for users of GNU find. We try hard to avoid surprising changes in behaviour. So I think it's safe to say that if there are no option arguments specified before the start points, the start points would be evaluated in the order they were given. That is, in the order they exist in argv. The caveat about "option arguments" there is intended to leave open the possibility that in the future some kind of parallel execution might be supported - but it would not be the default. The xargs program already supports parallel execution (-P), for what it's worth. James.
