Jeff Weber <[EMAIL PROTECTED]> writes:
> (/bin/kill is required. The bash builtin kill cannot kill
> an entire process group.)
Sure it can.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 5
Jeff Weber wrote:
(/bin/kill is required. The bash builtin kill cannot kill
an entire process group.)
Well, assuming you know that /bin/kill is what you want. In my case I
know I would want to use 'env kill ' instead. (Does bash really
not have any other way to suppress built-ins?)
--
Matt
Jeff Weber <[EMAIL PROTECTED]> writes:
> 1) since the background job is started by one non-interactive script, and
> killed by another non-interactive script, job control does not enter into the
> solution.
Without job control you won't get a separate process group. Interactivity
and job contr
Andreas:
Thanks. I've been experimenting with this and making some progress. In
summary, I've found:
1) since the background job is started by one non-interactive script, and
killed by another non-interactive script, job control does not enter into the
solution.
2) The second "killing" scri
Jeff Weber <[EMAIL PROTECTED]> writes:
> enable job control,
$ set -m
> and kill the entire backgrounded job from a second
> non-interactive script?
You send the signal to the process group.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5,
Andreas:
On Tuesday 06 March 2007 12:40, Andreas Schwab wrote:
> Jeff Weber <[EMAIL PROTECTED]> writes:
> > Here's some sample code:
> >
> > # create a backgrounded subshell to execute long-running processes
> > #( sleep 300 && sleep 400 && sleep 500 )& # doesn't work, bummer
> > $SHELL -c "
Jeff Weber <[EMAIL PROTECTED]> writes:
> Here's some sample code:
>
> # create a backgrounded subshell to execute long-running processes
> #( sleep 300 && sleep 400 && sleep 500 )& # doesn't work, bummer
> $SHELL -c "sleep 300; sleep 400; sleep 500" & # doesn't work, bummer
> pid=$!
> echo
I have a situation whereby my script may encounter commands which may block
for a "long time", before completion. However, for other reasons, my initial
script must complete "quickly".
My solution has been to encapsulate the blocking commands in a subshell, then
run the subshell in the backgro
On Mon, 5 Mar 2007 17:49:47 -0500
Chet Ramey <[EMAIL PROTECTED]> wrote:
> Bash-Release: 3.2
> Patch-ID: bash32-010
I'm still seeing a difference in behaviour:
$ cat ~/bash-test
v="Alphabet"
[[ ${v} =~ "Alphabet" ]] && echo match 1 || echo no match 1
[[ ${v} =~ 'Alphabet' ]] && echo match 2 || ec
On Mon, 2007-03-05 at 17:49 -0500, Chet Ramey wrote:
> The glibc implementation of regcomp/regexec does not allow backslashes to
> escape "ordinary" pattern characters when matching. Bash used backslashes
> to quote all characters when the pattern argument to the [[ special
> command's =~ operator
10 matches
Mail list logo
