[adding the 'bug-findutils' ML again]
Please keep the discussion on the public mailing list, as others can also read
it, thanks.
On 10/17/19 9:05 AM, francoisgr...@free.fr wrote:
> On 10/16/19 18:14, "Bernhard Voelker" <m...@bernhard-voelker.de> wrote:
>> On 10/16/19 4:54 PM, francoisgr...@free.fr wrote:
>>> I've been looking for a breadth-first search option for the find command,
but found none. Is there anyone ?
>>> If no, would it be possible to add it ?
>> no, find(1) processes the directory hierarchy as provided by gnulib's FTS
module,
>> or alternatively with -depth.
>>
>> For the results of the search, this should not matter ... well, for the order
>> of the output, it obviously does.
>>
>> If you would want to process each directory level first, and then go down,
>> then I suggest to use the "decorate-sort-undecorate" approach by printing
>> the current depth (%d), then sort by that, and finally remove the depth
>> from the input during the subsequent, actual processing, e.g.:
>>
>> $ find . -printf '%d %p\0' \
>> | LC_ALL=C sort -z -k1,1n \
>> | xargs -0 \
>> sh -c '\
>> while [ $# -gt 0 ]; do \
>> d="${1%% *}"; \
>> e="${1#* }"; \
>> shift 1; \
>> echo "processing (depth $d): entry: \"${e}\""; \
>> done' sh
>> processing (depth 0): entry: "."
>> processing (depth 1): entry: "./a"
>> processing (depth 2): entry: "./a/b"
>> processing (depth 2): entry: "./a/f"
>> processing (depth 3): entry: "./a/b/c"
>> processing (depth 3): entry: "./a/b/e"
>> processing (depth 3): entry: "./a/f/g"
>> processing (depth 3): entry: "./a/f/h"
>>
>> As the need for such breadth-first processing seems to be quite
>> seldom, and one can work around this with an approach like the
>> above, I currently wouldn't see a reason to add this (or another)
>> traversal algorithm to find(1).
>
> Hello Bernhard,
Hi Francois,
> Thank you for your answer.
>
> I tried your solution, it works. I also found other ones in forums where
people look for a bds option of find.
> On the other hand (I don't mean to be harsh, please forgive me if I'm), it is
not very elegant.
I see it completely different: actually this _is_ elegant:
it combines the tools according to the UNIX philosophy, i.e., one tool for one
purpose.
It does not make sense to put all features into all tools, especially if
there's already
a way to work around it with some easy piping data into another tool.
Admittedly, the shell script in the latter part looks a bit complex, but this
was just
to demonstrate what that part should do ... we still don't know your actual use
case.
> Breadth first is kind of the symetric method of depth first, and find would
gain in symetry completeness with a bfs like option.
> Unless it would break the code or too complicated ? What do you think ?
The 'find -depth' option does not work like a 100% depth-first algorithm.
Instead, if just ensures, that leaves are processed earlier than their
parents:
$ find -depth
./a/f/g
./a/f/h
./a/f
./a/b/c
./a/b/e
./a/b
./a
.
There could be any strategy added to walk the tree, but this would add
much bloat to the code. Look at the code: having the regular and
the -depth alternatives make this matter already complex enough.
You didn't mention it yet - apart from something like "would be nice" -,
so what would be an actual use case for a true depth-first or breadth-first
strategy?
> Regards :-)
> Francois
Have a nice day,
Berny
