svn commit: r217557 - in head: bin/sh tools/regression/bin/sh/execution

[Jilles Tjoelker]

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 at freebsd.org> wrote:
> > On 01/18/2011 14:33, Garrett Cooper wrote:
> >> On Tue, Jan 18, 2011 at 1:18 PM, Jilles Tjoelker<jilles at 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