On 04/14/2011 03:07 AM, Roman Rakus wrote:
Or document current behavior.
What about following?
diff -up bash-4.2/doc/bash.1.trap bash-4.2/doc/bash.1
--- bash-4.2/doc/bash.1.trap2011-04-14 08:10:47.0 +0200
+++ bash-4.2/doc/bash.1 2011-04-14 08:15:34.0 +0200
@@ -9424,6 +9424,7
On 04/13/2011 03:45 PM, Chet Ramey wrote:
On 4/12/11 11:04 PM, Roman Rakus wrote:
On 04/12/2011 03:30 PM, Chet Ramey wrote:
Probably because it's very old code. That has been there essentially
unchanged since at least bash-1.12 -- almost twenty years ago. It would
be better to block the signa
On 4/12/11 11:56 PM, Mike Frysinger wrote:
> seems to be just like the bug fixed in bash41-006, but with a diff for loop
Yep, and with the same one-line fix. I'm looking at other cases that might
require it.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
On Wed, Apr 13, 2011 at 12:28:39PM -0700, Greg Wooledge wrote:
> On Wed, Apr 13, 2011 at 11:19:22AM -0700, Ray Van Dolson wrote:
> > I'm trying to get regular expression matching working on both bash v3
> > as well as v4.
>
> Put the RE in a variable.
>
> > The following works on v4 (under RHEL6)
On Wed, Apr 13, 2011 at 11:19:22AM -0700, Ray Van Dolson wrote:
> I'm trying to get regular expression matching working on both bash v3
> as well as v4.
Put the RE in a variable.
> The following works on v4 (under RHEL6), but not under bash 3.00.15
> (under RHEL4):
>
> [[ "6Server" =~ ([0-9]+)(.
I'm trying to get regular expression matching working on both bash v3
as well as v4.
The following works on v4 (under RHEL6), but not under bash 3.00.15
(under RHEL4):
[[ "6Server" =~ ([0-9]+)(.*) ]]
This works on 3.00.15, but not under RHEL6's bash (4.1.2):
[[ "6Server" =~ '([0-9]+)(.*)' ]]
T
On 4/12/11 11:04 PM, Roman Rakus wrote:
> On 04/12/2011 03:30 PM, Chet Ramey wrote:
>> Probably because it's very old code. That has been there essentially
>> unchanged since at least bash-1.12 -- almost twenty years ago. It would
>> be better to block the signal while the trap string and handler
Chet Ramey wrote:
> On 4/7/11 8:06 AM, sbra...@suse.cz wrote:
> > Description:
> > Warning "execute_coproc: coproc [$PID:.*] still exists" as it is
> > implemented makes no sense. It appears in many situations where
> > it is done intentionally and it is not easy to silence it.
> The w