bash drops errexit option in sourced file
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2
-L/home/abuild/rpmbuild/BUILD/bash-4.2/../readline-6.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu'
-DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib
-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector
-funwind-tables -fasynchronous-unwind-tables -g -D_GNU_SOURCE
-DRECYCLES_PIDS -Wall -g -std=gnu89 -Wuninitialized -Wextra
-Wno-unprototyped-calls -Wno-switch-enum -Wno-unused-variable
-Wno-unused-parameter -ftree-loop-linear -pipe -fprofile-use
uname output: Linux linux-e1lq 3.4.11-2.16-desktop #1 SMP PREEMPT Wed
Sep 26 17:05:00 UTC 2012 (259fc87) x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-suse-linux-gnu
Bash Version: 4.2
Patch Level: 24
Release Status: release
Description:
While normally sourced files have identical options set like the
invoking environment this is not true if the sourcing is done from
within a function foo that was called with something like:
foo && true
The following example demonstrates this:
$ cat bug
#!/bin/bash
set -e
int()
{
echo A: $-
. source
echo D: $-
}
echo Broken:
int && true
echo OK:
int
$ cat source
echo B: $-
false
echo C: $-
$ bash bug
Broken:
A: ehB
B: hB
C: hB
D: ehB
OK:
A: ehB
B: ehB
$
This error showed up in bash 4.0 first and was not present in 3.2 or older.
As you can see in the invocation "int && true" the flag is still set
inside the function but magically disappears once the file is sourced,
while in the second incocation "int" everything behaves as expected.
Apparently something gets broken when the exit on error is temporarily
disabled for the chained command "int && true" because while it gets
properly restored within the function itself it disappears again when
sourcing the other file.
This problem was also reported already as
https://savannah.gnu.org/support/index.php?108191 already but Werner
Fink suggested to report via bashbug.
Repeat-By:
Invoke the scripts as described in the details section.
Re: bash drops errexit option in sourced file
On 12/3/12 4:12 AM, Robert Schiele wrote:
> Bash Version: 4.2
> Patch Level: 24
> Release Status: release
>
> Description:
> While normally sourced files have identical options set like the
> invoking environment this is not true if the sourcing is done from
> within a function foo that was called with something like:
>
> foo && true
>
> The following example demonstrates this:
>
> $ cat bug
> #!/bin/bash
> set -e
>
> int()
> {
> echo A: $-
> . source
> echo D: $-
> }
>
> echo Broken:
> int && true
>
> echo OK:
> int
> $ cat source
> echo B: $-
> false
> echo C: $-
> $ bash bug
> Broken:
> A: ehB
> B: hB
> C: hB
> D: ehB
> OK:
> A: ehB
> B: ehB
> $
>
> This error showed up in bash 4.0 first and was not present in 3.2 or older.
>
> As you can see in the invocation "int && true" the flag is still set
> inside the function but magically disappears once the file is sourced,
> while in the second incocation "int" everything behaves as expected.
> Apparently something gets broken when the exit on error is temporarily
> disabled for the chained command "int && true" because while it gets
> properly restored within the function itself it disappears again when
> sourcing the other file.
Since the `source' command is called in a context where all commands within
it should have the `errexit' flag disabled, bash chooses to satisfy this
requirement by turning off the flag that (internally) represents errexit.
Under most circumstances, however, that state is externally visible as the
value of the -e option.
Note that the behavior of suppressing the effect of the errexit option is
correct. The value of the -e option in $- should be unaffected, though.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: IFS is ignored for nested functions with stdin redirection
В Sun, 02 Dec 2012 22:33:14 -0500 Chet Ramey пишет: > On 12/2/12 11:52 AM, Andrey Borzenkov wrote: > > I hit this problem in DKMS code and could reduce it to the following > > example: > > Thanks for the report. The problem has to do with state in the process > substitution subshell preventing it from using the temporary environment > for variable lookups. It will be fixed in the next version. I have > attached a patch; please let me know if it fixes the issue for you. > Yes, this fixed it. Thank you!
Re: bash drops errexit option in sourced file
On Mon, Dec 3, 2012 at 4:25 PM, Chet Ramey wrote: > Since the `source' command is called in a context where all commands within > it should have the `errexit' flag disabled, bash chooses to satisfy this > requirement by turning off the flag that (internally) represents errexit. > Under most circumstances, however, that state is externally visible as the > value of the -e option. > > Note that the behavior of suppressing the effect of the errexit option is > correct. The value of the -e option in $- should be unaffected, though. Ah, now I start to understand how this is supposed to work. I also realized that it is not possible within the function to turn on the flag again with another internal set -e. Is that also part of the design, meaning there is no way to have an effective set -e within a function in case it was called in that context? Robert
Re: bash drops errexit option in sourced file
On 12/3/12 10:50 AM, Robert Schiele wrote: > On Mon, Dec 3, 2012 at 4:25 PM, Chet Ramey wrote: >> Since the `source' command is called in a context where all commands within >> it should have the `errexit' flag disabled, bash chooses to satisfy this >> requirement by turning off the flag that (internally) represents errexit. >> Under most circumstances, however, that state is externally visible as the >> value of the -e option. >> >> Note that the behavior of suppressing the effect of the errexit option is >> correct. The value of the -e option in $- should be unaffected, though. > > Ah, now I start to understand how this is supposed to work. I also > realized that it is not possible within the function to turn on the > flag again with another internal set -e. Is that also part of the > design, meaning there is no way to have an effective set -e within a > function in case it was called in that context? Correct. When called in a context where errexit is ignored, attempts to turn errexit on are ineffective. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash drops errexit option in sourced file
On 12/3/12 11:07 AM, Chet Ramey wrote: > On 12/3/12 10:50 AM, Robert Schiele wrote: >> On Mon, Dec 3, 2012 at 4:25 PM, Chet Ramey wrote: >>> Since the `source' command is called in a context where all commands within >>> it should have the `errexit' flag disabled, bash chooses to satisfy this >>> requirement by turning off the flag that (internally) represents errexit. >>> Under most circumstances, however, that state is externally visible as the >>> value of the -e option. >>> >>> Note that the behavior of suppressing the effect of the errexit option is >>> correct. The value of the -e option in $- should be unaffected, though. >> >> Ah, now I start to understand how this is supposed to work. I also >> realized that it is not possible within the function to turn on the >> flag again with another internal set -e. Is that also part of the >> design, meaning there is no way to have an effective set -e within a >> function in case it was called in that context? > > Correct. When called in a context where errexit is ignored, attempts to > turn errexit on are ineffective. I should note that there's a potential problem with the effect of turning on set -e in a sourced file even when it's called from a function in a context where errexit is ignored. Bash allows set -e to be enabled within the sourced file and have its usual short-circuiting effect. That's probably not quite the right thing to do, so I will have to take a look at it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: "And" extended matching operator
On Wednesday, November 28, 2012 07:23:17 PM Nikolai Kondrashov wrote:
> @(a&!(b))
This is the syntax ksh93 already uses. So far nobody else has adopted it, but
the equivalent as you already mentioned is the transformation to:
!(!(...)|!(...))
It's just a matter of implementing it. Other handy matching features still
missing are the non-greedy modifier for pattern-lists, arbitrary quantifiers,
and grouping for patterns (already supported for ERE only with BASH_REMATCH,
but there's no .sh.match equivalent.)
Of these, I think the non-greedy modifier and {n,m} quantifiers for patterns
would be my priorities because ERE doesn't support either non-greedy matching
or negative assertions, while only ERE supports custom quantification and
grouping. There's also no way to use ERE for globbing, only for pattern
matching, without also adding the ~(...) syntax, which would be a huge
undertaking.
--
Dan Douglas
