Re: findutils xargs.c change request

Hi David,

please send reports like this to the GNU findutils mailing list instead of using personal email.

On 2/17/26 18:12, David Marceau wrote:
> https://cgit.git.savannah.gnu.org/cgit/findutils.git/tree/xargs/xargs.c#n1369 <https://cgit.git.savannah.gnu.org/cgit/ 
> findutils.git/tree/xargs/xargs.c#n1369>
> 
> I wish to have it be replaced with this:

Thanks for the report and the suggested code change.

> if (E2BIG != errno)
>    {
>      error (0, 0, "%s: %s", strerror (errno), argv[0]);
>    }

Using strerror() is not necessary as error() already caters for it.

> Ultimately it's because when I read the errors coming from xargs.
> For example a build task.
> 
> GEN     kernel/kheaders_data.tar.xz
> xargs: perl: No such file or directory

It would have been nice to see the executed command line.  Assuming you are using
decent Makefile style one would probably see that with 'make $TARGET VERBOSE=yes V=1'.

Still, that's easy to craft a trivial reproducer:

   $ echo hello | xargs no-such
   xargs: no-such: No such file or directory

This means that the program 'xargs' had a problem with 'no-such', an the error was ENOENT.

> When I look at these 2 lines, I make a lot of assumptions to truly decipher it correctly.
> 
> interpretation 1) ok so perl was called and it didn't find a file...was it kernel/kheaders_data.tar.xz that is couldn't 
> find?
> interpretation 2) ok so there is a word perl and right after it, it says no such file or directory. Am I to understand 
> it means that no such file or directory called perl?
> interpretation 3) Ok tar.xz is there, ok xargs launched, ok perl launched ok...there's an empty parameter perl was 
> expecting. What was the variable name holding the empty parameter? What was the kind of value it was supposed hold? Give 
> me a hint?tar? script? wtf!

Other errors from the called program look like ... well, whatever the program or command outputs.
E.g.

   $ echo hello | xargs du --no-such-option
   du: unrecognized option '--no-such-option'
   Try 'du --help' for more information.

> In my mind, the error should appear first and then display the location of the error line/column along with the full 
> file path in question.
> The above output fails to explicitly describe the error in a manner that is easy to read.
> SUGGESTION: I am asking that within the build scripts error strings contain complete sentences describing the situation 
> also clearly specifying fieldnames and their respective values that to this error. This will help mitigate 
> misinterpretations. Don't make the reader try to read your mind, express error message clearly and give as much 
> information as you can as to what led to this.
> 
> Thank you.  I know the odds of this change being admitted are slim but at least it helps to understand why it might be 
> saving a lot of interpretation time from others if we made complete sentences in error strings.

I agree that the error diagnostic is a bit brief, yet I'd like to change it to what the
GNU coreutils do in the utilities like chroot(1), nohup(1), split(1) and timeout(1).

   $ echo hello | xargs/xargs no-such
   xargs/xargs: failed to run command 'no-such': No such file or directory

Pushed the attached.

Have a nice day,
Berny

From c356ebc5bbab38b20109026b335c5118c1fe69d4 Mon Sep 17 00:00:00 2001
From: Bernhard Voelker <[email protected]>
Date: Mon, 23 Feb 2026 22:09:14 +0100
Subject: [PATCH] xargs: improve error diagnostic when execvp fails

* xargs/xargs.c (xargs_do_exec): Use translation string to diagnose
that running the command via execpv failed, and quote the given command
appropriately.
* NEWS (Improvements): Mention the change.

Reported by David Marceau.
---
 NEWS          | 5 +++++
 xargs/xargs.c | 3 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index d4002688..aa99ccf3 100644
--- a/NEWS
+++ b/NEWS
@@ -39,6 +39,11 @@ GNU findutils NEWS - User visible changes.      -*- outline -*- (allout)
   are passed with a leading dash, e.g. '-!'.  Future releases will not accept
   that any more.  Accepting that was rather a bug "since the beginning".
 
+** Improvements
+
+  xargs now gives a better error diagnostic when executing the given command
+  failed.
+
 ** Documentation Changes
 
   The forthcoming Issue 8 of the POSIX standard will standardise "find
diff --git a/xargs/xargs.c b/xargs/xargs.c
index 7ff17f51..262a64cf 100644
--- a/xargs/xargs.c
+++ b/xargs/xargs.c
@@ -1368,7 +1368,8 @@ xargs_do_exec (struct buildcmd_control *ctl, void *usercontext, int argc, char *
             close (fd[1]);
             if (E2BIG != errno)
               {
-                error (0, errno, "%s", argv[0]);
+                error (0, errno, _("failed to run command %s"),
+                       quotearg_n_style (0, locale_quoting_style, argv[0]));
               }
             /* The actual value returned here should be irrelevant,
              * because the parent will test our value of errno.
-- 
2.52.0