On Fri, 24 Feb 2012, Jilles Tjoelker wrote:
On Sat, Feb 25, 2012 at 04:27:35AM +1100, Bruce Evans wrote:
...
Utilities are quite broken near here too:
- under -current:
- utilities still don't support signals >= 32, but give better error
messages.
kill(1) (both /bin/kill and the 9.x/10.x sh builtin) has passed
arbitrary signal numbers to kill(2) for quite a while.
Apparently I got confused by testing several versions. In -current,
the bugs are just that:
- bash-4.2 builtin kill doesn't understand signals >= 32, despite
supposedly being configured for FreeBSD
- bash-4.2 prints confusing termination messages which made me think
that /bin/kill didn't work:
- for signal 127, it prints "Stopped ..."
- for signal 126, it prints "Unknown signal: 126". I didn't notice
this was printed by bash(1) and not by kill(1).
A bug in builtin kill turned up: with kill(1), both bash and sh print
the termination message immediately, with builtin kill neither prints
it until a newline is entered.
Modified: head/usr.bin/xargs/xargs.c
==============================================================================
--- head/usr.bin/xargs/xargs.c Fri Feb 24 12:32:50 2012 (r232107)
+++ head/usr.bin/xargs/xargs.c Fri Feb 24 12:35:17 2012 (r232108)
@@ -608,8 +608,11 @@ waitchildren(const char *name, int waita
* If utility signaled or exited with a value of 255,
* exit 1-125.
*/
This comment didn't match the code before (the code always exited with
status 1), and is now further from matching the code.
This comment is hard to parse.
It seems to repeat a POSIX requirement. I suppose it can go away as it
doesn't really say anything the code doesn't say.
It's harder to parse than I thought :-). FreeBSD man pages are very
bad about distinguishing POSIX requirements from what the implementation
does (they mostly give the implementation behaviour without saying that).
Some source code says "POSIX requires...".
This misclassifies signal 127 due to the above bug.
+ if (WEXITSTATUS(status) == 255)
+ errx(1, "%s: exited with status 255, aborting", name);
if (WEXITSTATUS(status))
rval = 1;
Neither WIFSTOPPED() nor WIFEXITED() are tested, so the result of the
misclassification is turning signal 127 into a normal exit with status
0. A normal WIFSTOPPED() should not get here, else job control would
just break xargs, so the bug can probably be worked around by turning
WIFSTOPPED() into WIFSIGNALED() here, or just blindly using WTERMSIG()
!= 0 to classify signals.
I don't think xargs should work around that bug, particularly not by
introducing unspecified behaviour (the value of WTERMSIG(x) when
!WIFSIGNALED(x)).
OK. So it needs to be disallowed in the kernel.
I wonder how 0177 came to mean stopped. The kernel doesn't use _WSTOPPED,
and doesn't seem to use 0177 or 0x7f.
The messages have a grammar error (comma splice).
GNU xargs has a semicolon instead of a comma. Is that better?
Yes.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
