Re: Bash-3.2 Official Patch 10
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 was quoted. This caused the match to fail on Linux
> and other systems using GNU libc.
There still doesn't seem to be a way to write expressions that work in
3.2 and in 3.1. For example, below is an expression that works fine in
3.1. How do I re-write it so that it (a) continues to work with
bash-3.1, and (b) also works with bash-3.2?
{ cat "$file" ; echo ; } | while read line; do
if [[ ! "$line" =~ '^[[:space:]]*(\#.*)?$' ]]; then
/sbin/ip rule del $line
fi
done
In particular, when the whole thing is de-quoted bash-3.1 seems to
require the parentheses to be escaped, while bash-3.2 seems to require
that they are *not* escaped.
Tim.
*/
signature.asc
Description: This is a digitally signed message part
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash-3.2 Official Patch 10
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 || echo no match 2
[[ ${v} =~ Alphabet ]] && echo match 3 || echo no match 3
[[ ${v} =~ "^Alpha" ]] && echo match 4 || echo no match 4
[[ ${v} =~ '^Alpha' ]] && echo match 5 || echo no match 5
[[ ${v} =~ ^Alpha ]] && echo match 6 || echo no match 6
bash 3.1.17(1):
$ source ~/bash-test
match 1
match 2
match 3
match 4
match 5
match 6
bash 3.2.10(1):
$ source ~/bash-test
match 1
match 2
match 3
no match 4
no match 5
match 6
To get the 3.2 results, I expected to have to write:
[[ ${v} =~ "\^Alpha" ]] && echo match 4 || echo no match 4
[[ ${v} =~ '\^Alpha' ]] && echo match 5 || echo no match 5
(which is what I think bash-3.2_p10 is effectively doing)
I tried reading the posix standard (well, the single-unix specification
at opengroup.org, base definitions chapter 9 and shells & utilitis
chapter 2) but things are not so clear to me. It still seems
counter-intuitive to me to have the regex characters auto-quoted in
single and double-quoted strings, just because they're the rhs of =~.
Doesn't happen if I pass one to grep, compare for example:
3.1:
$ v="Alphabet"
$ [[ ${v} =~ "^Alpha" ]] && echo matches
matches
$ echo ${v} | grep "^Alpha"
Alphabet
3.2.10
$ v="Alphabet"
$ [[ ${v} =~ "^Alpha" ]] && echo matches
$ echo ${v} | grep "^Alpha"
Alphabet
I guess the question is, is the difference between 3.2.10 and 3.1
semantics for the =~ rhs as described above intended?
--
Kevin F. Quinn
signature.asc
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
signal propogation to backgrounded subshells
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 background. Thus the parent script can complete quickly. The background subshell needs to execute a serial list of commands. (During script development, I am using sleep to mimic blocking commands.) The problem occurs when trying to cleanup the backgrounded subshell, if it is still active. I would like to be able to send a signal to the subshell, which would terminate the subshell and all active subshell commands. This is not the behavior I am seeing. Rather, I am seeing the subshell bash process terminate, but the currently active subshell child process continues to execute, with a new parent pid of 1 (init). That is, the signal kills the subshell, but not the active subshell child process. Again, I want every process associated with the subshell to die upon receipt of the signal. 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 background job $pid When I run this, it announces the background job pid, which I then kill. I've tried SIGHUP, SIGINT, SIGTERM. The backgrounded bash job terminates as expected. However, the active sleep job continues to execute, now being owned by init. Somehow, it "escaped". I want any active sleep job to die too. Is this a bug, feature, or misunderstanding? Regardless, is there a simple solution to get the behavior I want? config: GNU bash, version 3.1.17(1)-release (i586-suse-linux) Copyright (C) 2005 Free Software Foundation, Inc. TIA, Jeff Weber ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: signal propogation to backgrounded subshells
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 background job $pid > > > When I run this, it announces the background job pid, which I then kill. > I've > tried SIGHUP, SIGINT, SIGTERM. The backgrounded bash job terminates as > expected. However, the active sleep job continues to execute, now being > owned by init. Somehow, it "escaped". I want any active sleep job to die > too. > > Is this a bug, feature, or misunderstanding? It's not a bug. You only kill a single process, no other processes are affected. > Regardless, is there a simple solution to get the behavior I want? You need to enable job control and kill the whole job. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: signal propogation to backgrounded subshells
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 "sleep 300; sleep 400; sleep 500" & # doesn't work, bummer > > pid=$! > > echo background job $pid > > > > > > When I run this, it announces the background job pid, which I then kill. > > I've tried SIGHUP, SIGINT, SIGTERM. The backgrounded bash job terminates > > as expected. However, the active sleep job continues to execute, now > > being owned by init. Somehow, it "escaped". I want any active sleep job > > to die too. > > > > Is this a bug, feature, or misunderstanding? > > It's not a bug. You only kill a single process, no other processes are > affected. > > > Regardless, is there a simple solution to get the behavior I want? > > You need to enable job control and kill the whole job. I scanned the bash man page and O'Reilly book and this looks difficult to do for my config: the backgrounded job is forked from non-interactive script1, and needs to be killed by noninteractive script2. The job control machinery looks tailored for use within the same interactive shell. If job control is the answer. How do I: enable job control, and kill the entire backgrounded job from a second non-interactive script? thanks, Jeff ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: signal propogation to backgrounded subshells
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, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: signal propogation to backgrounded subshells
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" script needs to perform an incantation of ps -ajx | awk "some awk expression" to discover the process group of the backgrounded job, then /bin/kill -s SIGTERM -pgrpid the target pgrpid. (/bin/kill is required. The bash builtin kill cannot kill an entire process group.) If the process group of the background job could be returned or queried when the background job is launched, I could save this, in say, /var/run, and make it much easier for the second "killing" script to discover the target process group. I don't see a direct bash mechanism for doing this. However, it looks like bash currently puts all backgrounded processes into a pgrp set from the pid of the parent shell. Thus, I could save the pid of the parent shell in /var/run. I don't know if I can depend upon this behavior in future releases. Please let me know if I am misunderstanding, and thanks for your help. Jeff On Tuesday 06 March 2007 14:25, Andreas Schwab wrote: > 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. -- Jeff Weber American Superconductor Corp. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: signal propogation to backgrounded subshells
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 control are orthogonal concepts. > If the process group of the background job could be returned or queried when > the background job is launched, That's what $! is for. > Please let me know if I am misunderstanding, and thanks for your help. Don't top post. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: signal propogation to backgrounded subshells
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?) -- Matthew "Do you do windows as well?" "Only when I'm forced to deal with Microsoft..." -- from a story by Feech ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: signal propogation to backgrounded subshells
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 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
