Debian Bug report logs - #611417
can't turn off job notification in scripts

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: jidanni@jidanni.org

To: submit@bugs.debian.org

Subject: can't turn off job notification in scripts

Date: Sat, 29 Jan 2011 10:37:06 +0800

Package: bash
Version: 4.1-3
Severity: minor

One cannot turn off this Terminated message, that shouldn't be on in
this case.

Nothing up my sleeve:
# su - nobody
No directory, logging in with HOME=/
nobody@jidanni2:/$ cd /tmp
nobody@jidanni2:/tmp$ cat t
sleep 11&
kill $!
sleep 0
nobody@jidanni2:/tmp$ sh t
t: line 3:  3027 Terminated              sleep 11
nobody@jidanni2:/tmp$ echo $-
himBH
nobody@jidanni2:/tmp$ set +m #even though not inherited by scripts anyway, worth a try.
nobody@jidanni2:/tmp$ sh t
t: line 3:  3030 Terminated              sleep 11

Of course I can eliminate the mysterious "sleep 0" I tacked on. That will fix it:

nobody@jidanni2:/tmp$ sed 2q t > u
nobody@jidanni2:/tmp$ sh u
nobody@jidanni2:/tmp$

Now the script finishes fast enough so that there is no time to print
the Terminated message. One could also exec 2> /dev/null. But all those
are botch workarounds.

Message #10 received at 611417@bugs.debian.org (full text, mbox, reply):

From: jidanni@jidanni.org

To: chet.ramey@case.edu

Cc: wooledg@eeg.ccf.org, bug-bash@gnu.org, 611417@bugs.debian.org

Subject: Re: set -m +m -x and the element of chance or is it race conditions?

Date: Sun, 30 Jan 2011 08:33:15 +0800

>>>>> "CR" == Chet Ramey <chet.ramey@case.edu> writes:
CR> Is it a problem?  Bash prints messages about signal-terminated processes --
CR> at least those that don't die due to SIGINT or SIGPIPE -- when the
CR> shell is not interactive.  Most people want to know when their jobs die
CR> and their scripts fail.

But some don't, but also don't want to do exec 2>/dev/null and take
other messages to the grave with it.

Plus it isn't documented, depends on having e.g., sleep 0 after it, and
in general looks like one big hack. And violates the set +mb promise!

CR> (And, by the way, historical versions of sh did the same thing.)
But not the oldest.

OK, never mind, I'll just do
sleep 11&
kill -INT $!
sleep 0

However you might want to document it there on the bash man page. There
is a lot about SIGINT, but not this.

Message #15 received at 611417@bugs.debian.org (full text, mbox, reply):

From: jidanni@jidanni.org

To: chet.ramey@case.edu

Cc: wooledg@eeg.ccf.org, bug-bash@gnu.org, 611417@bugs.debian.org

Subject: Re: set -m +m -x and the element of chance or is it race conditions?

Date: Sun, 30 Jan 2011 08:34:48 +0800

Don't forget to mention that there better be e.g., at least a sleep 0
after it, if they want to be sure to see the message.

Message #20 received at 611417@bugs.debian.org (full text, mbox, reply):

From: Chet Ramey <chet.ramey@case.edu>

To: jidanni@jidanni.org

Cc: 611417@bugs.debian.org, wooledg@eeg.ccf.org, bug-bash@gnu.org, chet.ramey@case.edu

Subject: Re: set -m +m -x and the element of chance or is it race conditions?

Date: Sat, 29 Jan 2011 20:51:50 -0500

On 1/29/11 7:33 PM, jidanni@jidanni.org wrote:
>>>>>> "CR" == Chet Ramey <chet.ramey@case.edu> writes:
> CR> Is it a problem?  Bash prints messages about signal-terminated processes --
> CR> at least those that don't die due to SIGINT or SIGPIPE -- when the
> CR> shell is not interactive.  Most people want to know when their jobs die
> CR> and their scripts fail.
> 
> But some don't, but also don't want to do exec 2>/dev/null and take
> other messages to the grave with it.
> 
> Plus it isn't documented, depends on having e.g., sleep 0 after it, and
> in general looks like one big hack. And violates the set +mb promise!

Is everything you don't like that's not explicitly documented a bug?  In
any case, a little thought should tell you why having the shell stick
around long enough to catch the child's death makes a difference.

And what is the `set +mb promise'?

> CR> (And, by the way, historical versions of sh did the same thing.)
> But not the oldest.

Umm...yes, the oldest.  The v7 Bourne shell did.  In fact, since we were
running 4.3 BSD back in the early days of working on bash, it's what we
used as a model for this behavior.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

Message #25 received at 611417@bugs.debian.org (full text, mbox, reply):

From: jidanni@jidanni.org

To: chet.ramey@case.edu

Cc: 611417@bugs.debian.org, wooledg@eeg.ccf.org, bug-bash@gnu.org

Subject: Re: set -m +m -x and the element of chance or is it race conditions?

Date: Sun, 30 Jan 2011 10:12:02 +0800

>>>>> "CR" == Chet Ramey <chet.ramey@case.edu> writes:
CR> Is everything you don't like that's not explicitly documented a bug?  In
CR> any case, a little thought should tell you why having the shell stick
CR> around long enough to catch the child's death makes a difference.

With me you can exclude the concept of thought. Never had, never will.
Therefore we need hard details on the man page. E.g., "make sure there is
at least a /bin/echo, or better yet sleep 0 after your command, not just a ':' or
echo, or else the shell might finish too quick to see the message".
"To always not see the message, kill(1) with -SIG..."

CR> And what is the `set +mb promise'?
OK, I thought those messages had to do with job control.

Send a report that this bug log contains spam.