I have a PS1
which shows the SHLVL if it's not 1 to quickly see if I'm in a subshell. This works as expected when using GNOME, but when I spawn a new terminal in Awesome WM (Mod4+Return) it always starts with SHLVL=2
or higher. Is this normal?
This is directly related to the number of times I have restarted Awesome (Mod4+Ctrl+r or pkill -HUP awesome
). Is there some way to avoid spawning new shells when restarting?
These commits seem to be relevant, since Awesome ends up running something like $SHELL -c ...
on HUP
, but I don't know enough C to fix it.
My /bin/sh
is dash
and my login shell is bash
.
Best Answer
I think I understand the why, but I don't have a complete fix.
The behavior of
SHLVL
depends on the shell. In dash and ksh (both pdksh and ksh93), only interactive instances incrementSHLVL
. In bash and zsh, all instances incrementSHLVL
, evenbash -c …
.If you observed a change in behavior after this patch, it's likely that your
/bin/sh
is dash and your$SHELL
is bash. Before , awesome was executing/bin/sh -c …
which didn't changeSHLVL
. After the patch, it is now executing$SHELL -c …
, i.e.bash -c …
, which incrementsSHLVL
.You could cheat by changing
SHLVL
inside Awesome. Hook into the startup code to decreaseSHLVL
by 1. I'm pretty sure this is possible without recompiling the C code, though I don't know the Lua code.