Why do new terminals in Awesome spawn with SHLVL>1?

Question

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.

Reported the issue.

Answer 1

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 increment SHLVL. In bash and zsh, all instances increment SHLVL, even bash -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 change SHLVL. After the patch, it is now executing $SHELL -c …, i.e. bash -c …, which increments SHLVL.

You could cheat by changing SHLVL inside Awesome. Hook into the startup code to decrease SHLVL by 1. I'm pretty sure this is possible without recompiling the C code, though I don't know the Lua code.