(Composed using 'bashbug')
From: yesxo...@protonmail.ch
To: bug-bash@gnu.org
Subject: in-line calls to functions cause "exit" in the function to act like
"return"
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-Wno-parentheses -Wno-format-security
uname output: Linux 523x.env.dtu.dk 5.11.22-100.fc32.x86_64 #1 SMP Wed May 19
18:58:25 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 5.0
Patch Level: 17
Release Status: release
Description:
When 'exit' is executed in a function called to "in-line" its output to stdout,
the 'exit' acts like return, leaving the function scope, but not terminating
the bash process.
Repeat-By:
Sample script:
#!/bin/bash
set -x
function bar()
{
exit 1
}
foo="$(bar)"
exit 0
Running:
$ ./foo.sh
++ bar
++ exit 1
+ foo=
+ exit 0
$ echo $?
0
The call of 'exit 1' in 'function bar' "should" cause the bash process to
terminate and declare its exit status as 1 to the kernel, unless my
understanding of bash(1) and its relation with the kernel is mistaken.
Fix:
I have to work around by doing more checks in calling functions. But, I've
only seen this in that "in-lining" mechanism, thus, that seems to be where the
problem lies.
The "fix" is for exit to do its job, irrespective of the function depth.
If I have seriously misunderstood things, I apologise for wasting your time.
I love bash(1), and thank all who have worked upon it.
Warm regards,
YesXorNo
