On Wed, May 21, 2025 at 1:51 AM Bernhard Voelker
<[email protected]> wrote:
> [snip]
> Although I like in general the idea to have more control over
> exit values in the caller, I have the suspicion that mapping to
> EXIT_FAILURE may be too simple:
>
> How to distinguish that from other find(1) errors?
> In your case 0 vs. non-Zero seems to be sufficient.
> But other / future use cases might need to directly pass back
> the exit value transparently (or even mapped) to find's exit code?
> For that, extending your approach might be problematic.
One idea would be to take the exit status from the command itself. So if you do
$ find -fail_exec -exec sh -c 'cat "$1" || exit 42' sh {} \;
then find would exit(42) if cat fails.
> For the user, it is already confusing to have so many flavors:
> -exec COMMAND ; -exec COMMAND {} + -ok COMMAND ;
> -execdir COMMAND ; -execdir COMMAND {} + -okdir COMMAND ;
> So adding another one adds complexity.
Unless I'm misreading it, the given patch doesn't add another variant
like that, it just adds an option. So usage would look like
$ find -fail_exec -exec false + {}
> On 5/20/25 22:56, Bernhard Voelker wrote:
> > So would you please describe further your use cases with some
> > examples?
>
> P.S. It makes sense looking over the fence as well:
> does one of the other find(1) implementations have such a feature
> already, and how is it solved there?
NetBSD find has -exit [status], so there you could write something like
$ find -exec cmd {} \; -o -exit 42
See https://man.netbsd.org/find.1
