If execfail is set, a failed exec does not cause a non-interactive shell to
exit, but it seems to reset the EXIT trap:
cat <<'EOF' | bash
shopt -s execfail
trap "echo exiting..." EXIT
exec ~/does-not-exist
echo "exec failed in bash-$BASH_VERSION"
exit 1
EOF
Output:
bash: line 3: /home/march/doe
:13 PM PDT, Alex fxmbsw7 Ratchev
wrote:
i think its not a bug but normal runtime
as ive understood, exec 'replaces' itself with , then no more
continued code
well error checking could maybe be better
On Fri, Oct 1, 2021, 01:25 Mark March wrote:
> If execfail is set, a fail
ey
wrote:
On 9/30/21 7:24 PM, Mark March wrote:
> If execfail is set, a failed exec does not cause a non-interactive shell to
> exit, but it seems to reset the EXIT trap:
Yes. When the shell runs `exec', it assumes the execed program will overlay
the shell process. To make that hap
her hand, not doing this will lead to subtle bugs where cleanup code will
suddenly not run, or processes unexpectedly catch signals that have been
previously blocked.
-Mark
On Friday, October 8, 2021, 08:02:31 AM PDT, Chet Ramey
wrote:
On 10/1/21 2:16 PM, Mark March wrote:
> Ok, thank yo
If -u is on and you declare a simple or associative array 'y' and set it empty,
then ${y@a} will fail with 'unbound variable'.
I was able to repro this under 5.1.0(1)-release and 5.1.8. 5.0.17(1)-release
does not seem to be affected.
The code to reproduce (output lines begin with #>):
echo $BAS
amp;& { set +u; ... set -u; } around my [[ ${foo@a} =~ A ]] for now.
Thanks again for your explanation and context.
-Mark
On Tuesday, October 26, 2021, 07:02:59 AM PDT, Chet Ramey
wrote:
On 10/25/21 8:24 PM, Mark March wrote:
> If -u is on and you declare a simple or associative array
true | { sleep 1 ; read -rt0 ; echo $?; }
outputs 0. There can clearly be no data on the stdin of the second process in
the pipeline.
bash(1) has this to say about read -t:
"If timeout is 0, read returns immediately, without trying to read any data.
The exit status is 0 if input is availabl
It appears that the same initialized nameref variable may refer to variables in
different scopes depending on the context where it is used. When used in an
assignment, a nameref will look for the variable it references starting at the
scope where the nameref itself was found, which may be below
I am working with a large Bash code base where most scripts disable job control
and the DEBUG trap is used extensively. I noticed that if I tried to run my
scripts in the background, the interactive shell that started them would
immediately exit on any keyboard input. A simple repro is to run
b
e any work-arounds
other than not using the DEBUG trap or leaving job control on?
-Mark
On Tuesday, June 18, 2024 at 02:48:51 PM PDT, Mark March
wrote:
I am working with a large Bash code base where most scripts disable job
control and the DEBUG trap is used extensively. I noticed th
Thank you for a quick fix. Bash 5.2.21 with the patch applied no longer
exhibits the problem in my tests.
-Mark
On Thursday, June 27, 2024 at 06:05:28 AM PDT, Chet Ramey
wrote:
On 6/18/24 4:55 PM, Mark March wrote:
> I am working with a large Bash code base where most scripts disa
lastpipe takes effect only if job control is off. From the man page:
lastpipe
If set, and job control is not active, the shell
With laspipe on and job control off, 'wait' appears to wait for all process
substitutions:
set +mshopt -s lastpipe
echo $'foo\nbar' | tee
12 matches
Mail list logo
