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
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
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
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
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
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
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
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
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
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)
10 matches
Mail list logo
