5

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.

Improve this question

1 Answer 1

Reset to default
5

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.

Improve this answer
1
  • I don't know what the behavior was before the patch, because I just started using Awesome after using Gnome for at least a year. Commented Feb 6, 2013 at 6:39

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.