On 5/3/25 17:07, Tomas Mudrunka wrote:
When find -exec is used in build scripts, ci pipelines and similar,
it's good to have way to ensure that failed subprocess executed
by find results in non zero return code of find as whole.
Thanks for the suggestion and the patch.
Previously this was only case with -exec {} +
Added option allows to enable this behavior globally.
Signed-off-by: Tomas Mudrunka <tomas.mudru...@gmail.com>
No need to sign off here - the author of the commit automatically has
signed it off. :-)
diff --git a/find/exec.c b/find/exec.c
index f281fcc0..1b34be82 100644
--- a/find/exec.c
+++ b/find/exec.c
@@ -384,6 +384,14 @@ launch (struct buildcmd_control *ctl, void *usercontext,
int argc, char **argv)
}
else
{
+ /* -fail_exec exits with failure immediately if invoked command fails.
+ */
+ if (options.fail_exec)
+ {
+ state.exit_status = EXIT_FAILURE;
+ error (1, errno, _("Exec %s returned %d"), argv[0], ex);
+ }
+
if (execp->multiple)
{
/* -exec \; just returns false if the invoked command fails.
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.
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.
Therefore, we'd need to understand better the context where this
addition would be useful. Then we could discuss that first, find
more similar or extended use cases, and then draft the user interface.
Wrt/ the implementation one could e.g. also add a flag option which
changes the error handling of the following -exec*/-ok* actions.
We had such discussions pretty fast on the GNU coreutils mailing
list when the timeout(1) command was introduced.
So would you please describe further your use cases with some
examples?
Thanks & have a nice day,
Berny
