Date: Wed, 13 Feb 2002 02:50:01 -0800 (PST) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/34898: [PATCH] rev 1.7 of xargs.c broke documented exit status Message-ID: <200202131050.g1DAo1U79985@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/34898; it has been noted by GNATS.
From: Bruce Evans <bde@zeta.org.au>
To: Tim Robbins <tim@robbins.dropbear.id.au>
Cc: <FreeBSD-gnats-submit@FreeBSD.ORG>
Subject: Re: bin/34898: [PATCH] rev 1.7 of xargs.c broke documented exit
status
Date: Wed, 13 Feb 2002 21:44:16 +1100 (EST)
On Wed, 13 Feb 2002, Tim Robbins wrote:
> >Description:
> Revision 1.7 of src/usr.bin/xargs/xargs.c, which changed the vfork() call
> to a fork(), broke the exit status 127 documented in xargs(1).
>
> It's broken in -STABLE and -CURRENT.
execvp() now uses alloca(), so it might be safe for xargs to use vfork()
again.
> >Fix:
>
> Index: xargs/xargs.c
> ===================================================================
> RCS file: /home/ncvs/src/usr.bin/xargs/xargs.c,v
> retrieving revision 1.11
> diff -u -r1.11 xargs.c
> --- xargs/xargs.c 2001/12/11 22:36:26 1.11
> +++ xargs/xargs.c 2002/02/13 05:32:54
> @@ -296,7 +296,6 @@
> run(argv)
> char **argv;
> {
> - volatile int noinvoke;
> char **p;
> pid_t pid;
> int status;
> @@ -308,21 +307,19 @@
> (void)fprintf(stderr, "\n");
> (void)fflush(stderr);
> }
> - noinvoke = 0;
> switch(pid = fork()) {
> case -1:
> err(1, "fork");
> case 0:
> execvp(argv[0], argv);
> warn("%s", argv[0]);
> - noinvoke = 1;
> - _exit(1);
> + _exit(254);
> }
> pid = waitpid(pid, &status, 0);
> if (pid == -1)
> err(1, "waitpid");
> /* If we couldn't invoke the utility, exit 127. */
> - if (noinvoke)
> + if (WEXITSTATUS(status) == 254)
> exit(127);
> /* If utility signaled or exited with a value of 255, exit 1-125. */
> if (WIFSIGNALED(status) || WEXITSTATUS(status) == 255)
The noinvoke hack has some advantages. Status 254 is a bit more fragile
than it used to be. There is now a signal 126 and killing any process
with this signal gives status 254.
Bugs found while testing this:
- /bin/kill doesn't support signals >= NSIG (32).
- I use an old version of bash-1 for a shell. It dumps core when a process
is killed by a signal >= 32. I think it was compiled when NSIG actually
gave the number of signals.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202131050.g1DAo1U79985>