From owner-svn-src-head@FreeBSD.ORG Fri Feb 24 22:10:07 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81EA2106566B; Fri, 24 Feb 2012 22:10:07 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 12D238FC17; Fri, 24 Feb 2012 22:10:06 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1OMA4QE012054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Feb 2012 09:10:05 +1100 Date: Sat, 25 Feb 2012 09:10:04 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jilles Tjoelker In-Reply-To: <20120224210141.GA3223@stack.nl> Message-ID: <20120225084319.P3207@besplex.bde.org> References: <201202241235.q1OCZH2U059017@svn.freebsd.org> <20120225024051.C1150@besplex.bde.org> <20120224210141.GA3223@stack.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans Subject: Re: svn commit: r232108 - head/usr.bin/xargs X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 22:10:07 -0000 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