On 5/21/25 19:24, Tavian Barnes wrote:
On Wed, May 21, 2025 at 1:51 AM Bernhard Voelker
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
On Wed, May 21, 2025 at 1:51 AM Bernhard Voelker
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
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?
Thanks & have a nice da
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 onl
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.
Previously this was only case with -exec {} +
Added option allows to enable this behavior globally.
Signed-
