From: yesxorno@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