Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question

1 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.

share|improve this answer
    
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. –  l0b0 Feb 6 '13 at 6:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.