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

[Jeff Chua]

On Tue, Nov 10, 2009 at 6:20 AM, Jan Schampera jan.schamp...@web.de 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

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

[Jeff Chua]

On Wed, Nov 11, 2009 at 12:44 AM, Chet Ramey chet.ra...@case.edu 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
} 21 | grep -v  Terminated
exit


Jeff

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

[Jeff Chua]

On Wed, Nov 11, 2009 at 12:04 PM, Jeff Chua jeff.chua.li...@gmail.comwrote:



 On Wed, Nov 11, 2009 at 12:44 AM, Chet Ramey chet.ra...@case.edu 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
 } 21 | 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
} 21 | grep -v  Terminated
exit


Thanks,
Jeff

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

[Jeff Chua]

On Mon, Nov 9, 2009 at 10:42 AM, Chet Ramey chet.ra...@case.edu 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.

[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.0 +0800
+++ bash/jobs.c 2009-11-06 23:55:17.0 +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))
{

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

[Jeff Chua]

On Sat, Nov 7, 2009 at 8:12 PM, Jan Schampera jan.schamp...@web.de 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

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

[Jeff Chua]

On Sun, Nov 8, 2009 at 5:25 AM, Chet Ramey chet.ra...@case.edu 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

Re: bash=~ bug or feature

[Jeff Chua]

On Thu, 17 May 2007, Bob Proulx wrote:


The behavior has been intentionally changed.

Please see Bash FAQ item E14.



Ok, thanks. I should have read the FAQ first.

Thanks,
Jeff.



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

[bash 3.1.5] sh -c echo -n ok broken

[Jeff Chua]

GNU bash, version 3.1.5(1)-release

sh -c echo -n ok returns -n ok.

This breaks a lot of scripts ... startup scripts in /etc/rc.d and many 
packages like glibc make check that use sh instead of bash with -n 
option.


How can I make sh -c echo -n ok returns ok instead -n ok?

I've tried compiling with --disable-strict-posix-default but that doesn't 
work.



Thanks,
Jeff


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: [bash 3.1.5] sh -c echo -n ok broken

[Jeff Chua]

On Wed, 18 Jan 2006, Chet Ramey wrote:


Somehow you've enabled the xpg_echo option, either by configuring
with --enable-xpg-echo-default or running `shopt -s xpg_echo'
somewhere.  I suspect the former.


Yes, I did --enable-xpg-echo-default as I need echo ok\c to work.

The older bash-3.00.15(3) works with --enable-xpg-echo-default.


So, it is possible to have both the following working in sh and bash

echo -n ok
echo ok\c

Thanks,
Jeff.




___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash