Odd Behavior: $SHLVL decreases in some situations with a pipe
From: H. Thiele
To: bug-bash@gnu.org
Subject: Odd Behavior: $SHLVL decreases in some situations with a pipe
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin14.5.0
Compiler: gcc
Compilation CFLAGS: -DSSH_SOURCE_BASHRC
uname output: Darwin ***REDACTED***.local 14.5.0 Darwin Kernel Version 14.5.0:
Sun
Jun 4 21:40:08 PDT 2017; root:xnu-2782.70.3~1/RELEASE_X86_64 x86_64
Machine Type: x86_64-apple-darwin14.5.0
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
In some situations (see Repeat-By) the value of the $SHLVL (Shell Level)
variable may
unexpectedly decrease by 1, e.g. when the stdout output of "printenv" is
redirected to
via a pipe.
While I noticed the behavior first when I installed the latest bash on my rusty
Mac OS X I also was able to reproduce it with bash 5.x under Debian and Raspian
on the
PI. On the other hand I don't see the effect with the old bash 3.x that came
with
Mac OS X.
Repeat-By:
$ printenv SHLVL
1
$ printf "%u\n" $SHLVL
1
$ printenv SHLVL | cat
0
$ printf "%u\n" $SHLVL | cat
1
Note how the result is "0" instead "1" for the 3rd command. Some more
experienced users
on Reddit (see:
https://www.reddit.com/r/bash/comments/vlrkk1/odd_behavior_of_shlvl_environment_variable/)
suggest following steps which may provide further clarification for the problem
with the
hint that it may has something to do with bash's "exec optimization", here is a
workaround
variant (courtesy of Reddit user aioeu) that successfully forwards the correct
information
to the next command by inserting a call to "true":
$ printenv SHLVL | cat
0
$ { printenv SHLVL; true; } | cat
1
Reddit user Electronic_Youth points out some other, perhaps related issue: if
one sets
SHLVL to a value higher than 999 a warning is generated when a new shell is
started, but
more interesting a warning is generated two times when printenv is used
(perhaps suggesting
some code runs twice?) I reproduced that double warning like this:
$ SHLVL=1001
$ printenv SHLVL | cat
bash: warning: shell level (1000) too high, resetting to 1
bash: warning: shell level (1000) too high, resetting to 1
1
Re: tab completing `/ cause weird errors messages.
On 6/25/22 8:27 PM, Emanuele Torre wrote: Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS uname output: Linux t420 5.15.48-1-lts #1 SMP Thu, 16 Jun 2022 13:32:35 + x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 16 Release Status: release Description: Tab completing `/ (backtick-slash) causes bash to print lots of weird error messages. Thanks for the report. It's trying to find the end of the directory name to see whether or not to append a slash. You can use $(/ instead, which behaves the way you want. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Odd Behavior: $SHLVL decreases in some situations with a pipe
On 6/27/22 8:02 AM, H. Thiele wrote: Bash Version: 5.1 Patch Level: 16 Release Status: release Description: In some situations (see Repeat-By) the value of the $SHLVL (Shell Level) variable may unexpectedly decrease by 1, e.g. when the stdout output of "printenv" is redirected to via a pipe. As you surmise, the behavior is related to bash optimizing away forks and using an implicit `exec' in the pipeline. I changed this particular case back last September as the result of https://lists.gnu.org/archive/html/help-bash/2020-10/msg00012.html which contains a pretty good discussion of the issue. Reddit user Electronic_Youth points out some other, perhaps related issue: if one sets SHLVL to a value higher than 999 a warning is generated when a new shell is started, but more interesting a warning is generated two times when printenv is used (perhaps suggesting some code runs twice?) I reproduced that double warning like this: $ SHLVL=1001 $ printenv SHLVL | cat bash: warning: shell level (1000) too high, resetting to 1 bash: warning: shell level (1000) too high, resetting to 1 1 It's slightly related. You get two messages because bash-5.1 tries to optimize away the exec in both subshells, and notices that SHLVL is too high when trying to adjust it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [ ! ! hey ] -> [: too many arguments
One more, and orry for the late reply, i waited until i could test also SunOS 5.9 test(1) (binary from 2002-04-07!). Emanuele Torre wrote in : |On 22/06/23 11:08 PM, Steffen Nurpmeso wrote: ... |bash-5.1$ test ! ! hey ; printf %s\\n "$?" ... |test(1) needs to treat the 0 to 4 arguments expressions specially |according to POSIX so the bug is probably only in the code that |implements those special cases. Anyhow it seems bash(1) [/test diverges from _all_ test(1)'s in my reach (SunOS, OpenBSD, NetBSD, FreeBSD, busybox, GNU coreutils). It can do what it wants, of course. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
