should xargs exit on non-zero program exit status?

should xargs exit on non-zero program exit status?

Post by Jonathan I. Kame » Sat, 10 Aug 1991 05:14:21

The 4.3-reno version of xargs contains the following code for actually running
the sub-program with arguments:

run(prog, argv)
        char *prog, **argv;
        union wait pstat;
        pid_t pid, waitpid();
        char **p;

        if (tflag) {
                (void)fprintf(stderr, "%s", *argv);
                for (p = argv + 1; *p; ++p)
                        (void)fprintf(stderr, " %s", *p);
                (void)fprintf(stderr, "\n");
        switch(pid = vfork()) {
        case -1:
                   "xargs: vfork: %s.\n", strerror(errno));
        case 0:
                execvp(prog, argv);
                   "xargs: %s: %s.\n", prog, strerror(errno));
        pid = waitpid(pid, &pstat, 0);
        if (pid == -1) {
                   "xargs: waitpid: %s.\n", strerror(errno));
        if (pstat.w_status)


Now, either the way the "stat" structure works under 4.3-reno is significantly
different, or the list two lines of this function will cause xargs to exit
completely if the program it's running exits with a non-zero exit status.

This strikes me as very wrong.  For example, one of the most common uses for
xargs is to run "find" on a tree and pipe the result through "xargs grep
string".  Well, with the behavior I've described above, xargs will exit as
soon as it gets a batch of files that don't have "string" in any of them, and
this strikes me as quite wrong.

So what's the story.... am I misunderstanding what the code does (which I
doubt, since I compiled it under SunOS 4.1.1 and it *is* exiting on the first
failed grep), or does 4.3-reno do things with the stat structure differently,
or does POSIX define the behavior I've described as "correct," or is this a
bug in 4.3-reno's xargs?



should xargs exit on non-zero program exit status?

Post by David J. MacKenz » Sat, 10 Aug 1991 07:14:03

Draft 11 of POSIX.2 specified the behavior you see in the reno xargs.
However, it has since been changed (in draft 11.1) to specify that the
program xargs is running has to exit with status 255 (a magic number)
to cause xargs to exit immediately; otherwise, it just causes xargs's
exit status to be nonzero, when xargs exits normally because of
reading EOF on the input.  There are other subtleties to the exit
status in draft 11.1 as well.

To summarize: xargs dying if the program it's running dies used to be
POSIX behavior, but it no longer is, because it was stupid.


1. Using non-zero exit status, procs, and if.

   >Note: I'm not talking about the ! operator in expressions.  We're
   >talking about reversing the sense of a command's success.  I.e.
   >something like
   >if ! tty -s

tty -s; case $? in
   0) dothis;;
   *) dothat;;

Net-Tamer V 1.08X - Test Drive

2. Help

3. /proc and truss -u option.

4. Forcing a non-zero exit status.....

5. Best Network monitoring program ?

6. kde startup problem: GiveConsole exited with a non-zero status

7. SCSI tape hangs

8. vi exits with non-zero status (Sol 2.5.1)

9. Non-zero exit code breaks bash loop

10. Exit status in trapped exit function

11. Do recent versions of xargs cope with exit status?

12. C++ program exits __start() with status 99