[PATCH] silent job monitor when 'set +m'

[Jeff Chua]

Chet,

The man page mentioned that 'set -m' should print 'a line containing their
status upon their completion' ... which should imply 'set +m' should NOT
print the status.

Attached is a patch to 'silent' bash so that it won't print the status
when 'Monitor mode' is off (set +m).

If this is not the right place to do this, please suggest an alternative
to silent bash when 'kill %!' is executed.


Thanks,
Jeff


--- bash/jobs.c.org 2009-11-06 20:26:13.000000000 +0800
+++ bash/jobs.c 2009-11-06 23:55:17.000000000 +0800
@@ -3489,8 +3489,12 @@
   signal_is_trapped (termsig) == 0)
  {
   /* Don't print `0' for a line number. */
-  fprintf (stderr, _("%s: line %d: "), get_name_for_error (), (line_number == 0) ? 1 : line_number);
-  pretty_print_job (job, JLIST_NONINTERACTIVE, stderr);
+  if(job_control) {
+  fprintf (stderr, _("%s: line %d: "),
+   get_name_for_error (),
+ (line_number == 0) ? 1 : line_number);
+  pretty_print_job (job, JLIST_NONINTERACTIVE, stderr);
+  }
  }
       else if (IS_FOREGROUND (job))
  {

[Jan Schampera]

Jeff Chua schrieb:

> The man page mentioned that 'set -m' should print 'a line containing
> their status upon their completion' ... which should imply 'set +m'
> should NOT print the status.
>
> Attached is a patch to 'silent' bash so that it won't print the status
> when 'Monitor mode' is off (set +m).
>
> If this is not the right place to do this, please suggest an alternative
> to silent bash when 'kill %!' is executed.
>
>
> Thanks,
> Jeff

A workaround is to diswon the monster. But yes, I also stumbled over
this once. See
http://bash-hackers.org/wiki/doku.php/snipplets/kill_bg_job_without_message


J.

[Jeff Chua]

On Sat, Nov 7, 2009 at 8:12 PM, Jan Schampera <jan.schampera@...> wrote:

> A workaround is to diswon the monster. But yes, I also stumbled over
> this once. See
> http://bash-hackers.org/wiki/doku.php/snipplets/kill_bg_job_without_message
>

"disown"... that's new to me. Nice. At least it's an alternative to "set
+m".

Thanks,
Jeff

[Chet Ramey]

Jeff Chua wrote:
>
> Chet,
>
> The man page mentioned that 'set -m' should print 'a line containing
> their status upon their completion' ... which should imply 'set +m'
> should NOT print the status.

I'm confused about the circumstances you used to trigger this behavior,
since the code fragment you modified is never executed by an interactive
shell, and non-interactive shells don't have job control enabled by
default.  Are you saying you ran a script in which you enabled job
control, ran a job, turned job control off, then killed the job?

Bash and historical versions of sh report the status of jobs in a script
that exit as the result of being killed by a signal.  I'm not going to
change that.

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

[Jeff Chua]

On Sun, Nov 8, 2009 at 5:25 AM, Chet Ramey <chet.ramey@...> wrote:

>
> Are you saying you ran a script in which you enabled job
> control, ran a job, turned job control off, then killed the job?
>

No, I didn't turn off job control. I use "set +m" to turn of monitoring only
because I don't want to see any message about the job being terminated.


> Bash and historical versions of sh report the status of jobs in a script
> that exit as the result of being killed by a signal.  I'm not going to
> change that.
>

Isn't that the purpose of "set +m" ... to turn off monitoring?

Thanks,
Jeff

[Chet Ramey]

Jeff Chua wrote:

>
>
> On Sun, Nov 8, 2009 at 5:25 AM, Chet Ramey <chet.ramey@...
> <mailto:chet.ramey@...>> wrote:
>
>
>     Are you saying you ran a script in which you enabled job
>     control, ran a job, turned job control off, then killed the job?
>
>
> No, I didn't turn off job control. I use "set +m" to turn of monitoring
> only because I don't want to see any message about the job being terminated.

I think you're confused about the distinction.  set -m and +m turn job
control on and off.  The `monitor' name is historical (ask Dave Korn
why he chose it).

>
>     Bash and historical versions of sh report the status of jobs in a script
>     that exit as the result of being killed by a signal.  I'm not going to
>     change that.
>
>
> Isn't that the purpose of "set +m" ... to turn off monitoring?

Let's take a step back.  I don't think your patch does what you think it
does, since the code it changes doesn't get executed when the shell is
interactive.

What version of bash are you using?  Assuming you mean an interactive
shell, bash-4.0 behaves like I think you want:

$ ./bash
$ echo $BASH_VERSION
4.0.35(9)-release
$ echo $-
himBH
$ sleep 40 &
[1] 19038
$ set +m
$ kill %1
$ fg %1
bash: fg: no job control
$ set -m
$ sleep 40 &
[1] 19041
$ kill %1
$
[1]+  Terminated              sleep 40
$

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

[Jeff Chua]

On Sun, Nov 8, 2009 at 10:14 AM, Chet Ramey <chet.ramey@...> wrote:

> I think you're confused about the distinction.  set -m and +m turn job
> control on and off.  The `monitor' name is historical (ask Dave Korn
> why he chose it).
>

That's what confused the whole issue.



> What version of bash are you using?


4.0.35(12)-release

 Assuming you mean an interactive shell, bash-4.0 behaves like I think you
> want:
>

> $ sleep 40 &
> [1] 19038
> $ set +m
> $ kill %1
> $ fg %1
> bash: fg: no job control
> $ set -m
> $ sleep 40 &
> [1] 19041
> $ kill %1
> $
> [1]+  Terminated              sleep 40
> $
>

That's exactly what I wanted. Thanks for the detailed sample!

Sorry for the confusion. Please ignore the patch. Bash as it is.

Jeff

[Jeff Chua]

> On Sun, Nov 8, 2009 at 5:25 AM, Chet Ramey <chet.ramey@...> wrote:

> non-interactive shells don't have job control enabled by default.  Are you
saying
> you ran a script in which you enabled job control, ran a job, turned job
control off,
>  then killed the job?

> Bash and historical versions of sh report the status of jobs in a script
> that exit as the result of being killed by a signal.  I'm not going to
> change that.

Chet,

Revisited. The previous reply to your example works fine for interactive
shell. But for a script  (non-interactive shell), the example does not work
the same. Job status are always reported even with "set +m" in the script.
...

Running the examples you gave in a "script" slightly enhanced to use "ps" to
show the processes with the following script.

$ cat /tmp/a1
#!/bin/bash
sleep 60 &
P=$!
/bin/ps Tfo "pid ppid command"
set -m
echo "\$-="$-
kill $P
/bin/ps Tfo "pid ppid command"

sleep 60 &
P=$!
/bin/ps Tfo "pid ppid command"
set +m
echo "\$-="$-
kill $P
/bin/ps Tfo "pid ppid command"



1) Case 1. Without patch.

$ /tmp/a1
  PID  PPID COMMAND
25048 25047 -bash
25774 25048  \_ /bin/bash /tmp/a1
25775 25774      \_ sleep 60
25776 25774      \_ /bin/ps Tfo pid ppid command
$-=hmB
  PID  PPID COMMAND
25048 25047 -bash
25774 25048  \_ /bin/bash /tmp/a1
25777 25774      \_ /bin/ps Tfo pid ppid command
/tmp/a1: line 8: 25775 Terminated              sleep 60
  PID  PPID COMMAND
25048 25047 -bash
25774 25048  \_ /bin/bash /tmp/a1
25778 25774      \_ sleep 60
25779 25774      \_ /bin/ps Tfo pid ppid command
$-=hB
  PID  PPID COMMAND
25048 25047 -bash
25774 25048  \_ /bin/bash /tmp/a1
25780 25774      \_ /bin/ps Tfo pid ppid command
/tmp/a1: line 16: 25778 Terminated              sleep 60



2) Case 2. With patch applied. "set +m" no longer reports job killed.
$ /tmp/a1
  PID  PPID COMMAND
25048 25047 -bash
26242 25048  \_ /bin/bash /tmp/a1
26243 26242      \_ sleep 60
26244 26242      \_ /bin/ps Tfo pid ppid command
$-=hmB
  PID  PPID COMMAND
25048 25047 -bash
26242 25048  \_ /bin/bash /tmp/a1
26245 26242      \_ /bin/ps Tfo pid ppid command
/tmp/a1: line 8: 26243 Terminated              sleep 60
  PID  PPID COMMAND
25048 25047 -bash
26242 25048  \_ /bin/bash /tmp/a1
26246 26242      \_ sleep 60
26247 26242      \_ /bin/ps Tfo pid ppid command
$-=hB
  PID  PPID COMMAND
25048 25047 -bash
26242 25048  \_ /bin/bash /tmp/a1
26248 26242      \_ /bin/ps Tfo pid ppid command


Is there another alternative to do this? "disown" would not work for
situation where "wait" is used to wait for child to finish  ...


sleep 80 &
P=$!
disown $P     # this would not work for 'wait' command next
(sleep 2; kill $P) &
wait $P


Thanks,
Jeff

[Chet Ramey]

Jeff Chua wrote:

> Revisited. The previous reply to your example works fine for interactive
> shell. But for a script  (non-interactive shell), the example does not
> work the same. Job status are always reported even with "set +m" in the
> script. ...

Right.  This is part of my previous answer, which you quoted:

>> Bash and historical versions of sh report the status of jobs in a script
>> that exit as the result of being killed by a signal.  I'm not going to
>> change that.

This functionality predates and is independent of job control.  Shells
back to at least the original Bourne shell (7th Edition) have done it.


> Is there another alternative to do this? "disown" would not work for
> situation where "wait" is used to wait for child to finish  ...

Sure.  Since the status messages are written to stderr, you can save
file descriptor 2 and temporarily (or permanently, depending on your
needs) redirect it to /dev/null.

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

[Jeff Chua]

On Mon, Nov 9, 2009 at 10:42 AM, Chet Ramey <chet.ramey@...> wrote:

> Sure.  Since the status messages are written to stderr, you can save
> file descriptor 2 and temporarily (or permanently, depending on your
> needs) redirect it to /dev/null.
>

That means another subshell.

Thanks for all your help.

Jeff.

[Chet Ramey]

> > Sure.  Since the status messages are written to stderr, you can save
> > file descriptor 2 and temporarily (or permanently, depending on your
> > needs) redirect it to /dev/null.
> >
>
> That means another subshell.

It doesn't require a subshell to save and restore stderr.

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

[Marc Herbert-5]

Chet Ramey a écrit :
>>> Sure.  Since the status messages are written to stderr, you can save
>>> file descriptor 2 and temporarily (or permanently, depending on your
>>> needs) redirect it to /dev/null.
>>>
>> That means another subshell.
>
> It doesn't require a subshell to save and restore stderr.

At first I thought the same. And then I read this:

<http://bash-hackers.org/wiki/doku.php/snipplets/kill_bg_job_without_message>

  It's also useless to temporarily redirect stderr when you call the
  kill command, since the successful termination of the job, the
  termination of the kill command and the message from the shell may not
  happen at the same time. And a blind sleep after the kill would be
  just a workaround.


Doesn't some permanently redirected subshell solves this race condition?

[Chet Ramey]

> > It doesn't require a subshell to save and restore stderr.
>
> At first I thought the same. And then I read this:
>
> <http://bash-hackers.org/wiki/doku.php/snipplets/kill_bg_job_without_message>
>
>   It's also useless to temporarily redirect stderr when you call the
>   kill command, since the successful termination of the job, the
>   termination of the kill command and the message from the shell may not
>   happen at the same time. And a blind sleep after the kill would be
>   just a workaround.
>
> Doesn't some permanently redirected subshell solves this race condition?

Maybe, but I don't think it's necessary.  I haven't tested it, but
what's wrong with

redirect stderr
kill pid
wait pid
restore stderr

It seems to me that this sequence forces the necessary synchronicity.

Chet

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

[Jan Schampera]

Chet Ramey schrieb:

> redirect stderr
> kill pid
> wait pid
> restore stderr
>
> It seems to me that this sequence forces the necessary synchronicity.

Interesting. And sad that I never thought of that.

Jan

[Jeff Chua]

On Tue, Nov 10, 2009 at 6:20 AM, Jan Schampera <jan.schampera@...> wrote:

> Chet Ramey schrieb:
>
> > redirect stderr
> > kill pid
> > wait pid
> > restore stderr
> >
> > It seems to me that this sequence forces the necessary synchronicity.
>
> Interesting. And sad that I never thought of that
>

Will you consider having like a new option "set -j" to switch displaying job
information on/off"?

Jeff

[Chet Ramey]

Jeff Chua wrote:

>
>
> On Tue, Nov 10, 2009 at 6:20 AM, Jan Schampera <jan.schampera@...
> <mailto:jan.schampera@...>> wrote:
>
>     Chet Ramey schrieb:
>
>     > redirect stderr
>     > kill pid
>     > wait pid
>     > restore stderr
>     >
>     > It seems to me that this sequence forces the necessary synchronicity.
>
>     Interesting. And sad that I never thought of that
>
>
> Will you consider having like a new option "set -j" to switch displaying
> job information on/off"?

I am inclined not, since there's a relatively easy workaround.

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

[Jeff Chua]

On Tue, Nov 10, 2009 at 11:09 PM, Chet Ramey <chet.ramey@...> wrote:

> Jeff Chua wrote:
> >
> >
> > On Tue, Nov 10, 2009 at 6:20 AM, Jan Schampera <jan.schampera@...
> > <mailto:jan.schampera@...>> wrote:
> >
> >     Chet Ramey schrieb:
> >
> >     > redirect stderr
> >     > kill pid
> >     > wait pid
> >     > restore stderr
> >     >
> >     > It seems to me that this sequence forces the necessary
> synchronicity.
> >
> >     Interesting. And sad that I never thought of that
> >
> >
> > Will you consider having like a new option "set -j" to switch displaying
> > job information on/off"?
>
> I am inclined not, since there's a relatively easy workaround.
>

How do you silent this one without a subshell. I just don't want to see the
"Terminated" output, but everything else in case there's error.

#!/bin/bash
sleep 60 &
P=$!
kill $P
sleep 1
exit


Currently, I'm doing it this way ...

#!/bin/bash
(
        sleep 60 &
        P=$!
        kill $P
        sleep 1
) 2>&1 | grep -v " Terminated"
exit


Thanks,
Jeff

[Chet Ramey]

Jeff Chua wrote:

>     > On Tue, Nov 10, 2009 at 6:20 AM, Jan Schampera
>     <jan.schampera@... <mailto:jan.schampera@...>
>     > <mailto:jan.schampera@... <mailto:jan.schampera@...>>> wrote:
>     >
>     >     Chet Ramey schrieb:
>     >
>     >     > redirect stderr
>     >     > kill pid
>     >     > wait pid
>     >     > restore stderr
>     >     >
>     >     > It seems to me that this sequence forces the necessary
>     synchronicity.
>     >
>     >     Interesting. And sad that I never thought of that
>     >
>     >
>     > Will you consider having like a new option "set -j" to switch
>     displaying
>     > job information on/off"?
>
>     I am inclined not, since there's a relatively easy workaround.
>
>
>
> How do you silent this one without a subshell.

What's wrong with the approach above?


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

[Jeff Chua]

On Wed, Nov 11, 2009 at 12:44 AM, Chet Ramey <chet.ramey@...> wrote:

> > How do you silent this one without a subshell.
>
> What's wrong with the approach above?
>

Nothing wrong, but can be made more efficient because "| grep" means another
subprocess which can be eliminated if the shell silents the Terminate
command in the first place.

#!/bin/bash
{
        sleep 60 &
        P=$!
        kill $P
        sleep 1
} 2>&1 | grep -v " Terminated"
exit


Jeff

[Jeff Chua]

On Wed, Nov 11, 2009 at 12:04 PM, Jeff Chua <jeff.chua.linux@...>wrote:

>
>
> On Wed, Nov 11, 2009 at 12:44 AM, Chet Ramey <chet.ramey@...> wrote:
>
>> > How do you silent this one without a subshell.
>>
>> What's wrong with the approach above?
>>
>
> Nothing wrong, but can be made more efficient because "| grep" means
> another subprocess which can be eliminated if the shell silents the
> Terminate command in the first place.
>
> #!/bin/bash
> {
>         sleep 60 &
>         P=$!
>         kill $P
>         sleep 1
> } 2>&1 | grep -v " Terminated"
> exit
>

Extending the example above slighting ... now with grep means I can't see
the message real-time anymore ... if you try the example below without the
grep, it should display 0 1 2 ... every second.

#!/bin/bash
{
        for((i = 0; i <100; i++))
        do
                echo " $i\c"
                sleep 1
        done &
        P=$!
        sleep 10
        kill $P
        sleep 1
        echo ok
} 2>&1 | grep -v " Terminated"
exit


Thanks,
Jeff