Date: Fri, 21 Jan 2011 13:32:43 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Garrett Cooper <gcooper@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Doug Barton <dougb@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r217557 - in head: bin/sh tools/regression/bin/sh/execution Message-ID: <20110121123243.GA58884@stack.nl> In-Reply-To: <AANLkTinxgfjBO4rvK0AgvXde_H4uT_iffyB4t43wRBuf@mail.gmail.com> References: <201101182118.p0ILIWA4052343@svn.freebsd.org> <AANLkTiku_GTXf=65m8RK4_RhD7ib5sZOzvvUFc26nvyJ@mail.gmail.com> <4D3631DE.8040408@FreeBSD.org> <AANLkTinxgfjBO4rvK0AgvXde_H4uT_iffyB4t43wRBuf@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 18, 2011 at 04:43:41PM -0800, Garrett Cooper wrote: > On Tue, Jan 18, 2011 at 4:35 PM, Doug Barton <dougb@freebsd.org> wrote: > > On 01/18/2011 14:33, Garrett Cooper wrote: > >> On Tue, Jan 18, 2011 at 1:18 PM, Jilles Tjoelker<jilles@freebsd.org> > >> wrote: > >>> Author: jilles > >>> Date: Tue Jan 18 21:18:31 2011 > >>> New Revision: 217557 > >>> URL: http://svn.freebsd.org/changeset/base/217557 > >>> Log: > >>> sh: Fix signal messages being sent to the wrong file sometimes. > >>> When a foreground job exits on a signal, a message is printed to > >>> stdout about this. The buffer was not flushed after this which > >>> could result in the message being written to the wrong file if > >>> the next command was a builtin and had stdout redirected. > > Does this mean that portmaster is going to stop printing those !*@%$@(# > > "Terminated" messages that I have never been able to figure out how to get > > rid of, or am I just a loser? :) > Don't know. I noticed it because the posix testsuite has a program > that traps SIGALRM (system/OS dependent signal number) for the purpose > of watchdog'ing testcases so they don't hang. So it was doing > something like this: > $ sh > $ python -c 'import os, signal; os.kill(0, signal.SIGALRM)' >/dev/null > 2>&1; echo $? > foo; echo "FOO:"; cat foo > FOO: > Alarm clock > 142 > $ > I would expect FOO: to follow Alarm clock, not precede it. > Whether or not this fixes portmaster, I dunno... try running bash > or dash instead of /bin/sh to see whether or not the `problem' still > occurs. > HTH, > -Garrett > PS Shells printing out Terminated, Alarm clock, etc is in the POSIX spec IIRC. I cannot find this, except if exiting on a signal other than SIGINT and SIGPIPE is implicitly considered an error that deserves a diagnostic message on stderr. I think that is another bug: as noted in the commit message this message is currently sent to stdout. It should be sent to stderr. In any case, a redirection directly on the command does not redirect the message but a redirection on an outer { ...; } compound command does (for pre-r217557 sh there should be a builtin or lone assignment without redirections within the compound command to make sure this works consistently). Another way to avoid the message is not exit on the signal, for example trap 'exit 1' TERM With subshells, there are additional complications. Normally, if the last thing a subshell needs to do is to fork a process and wait for it, it will not fork but instead perform the operation (typically execve()) directly. This is more efficient and makes $! more useful. However, it also means any message about a signal is not written by the subshell but by its parent. The exact details about this have changed between 7.x and 8.0, and may change again for 9.0. Some shells such as sh before r217557 also generate messages about signals from the wait builtin if it is used with parameters. I may put this back, sending them to stderr. These messages can be suppressed easily by redirecting wait's stdout and stderr. A somewhat related message is one that shows the job id and process ids of background jobs started in interactive mode. I cannot find a requirement for this in POSIX but most shells other than ash variants print it and it seems useful. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110121123243.GA58884>