0

I'm using "Red Hat Enterprise Linux Server release 7.1 (Maipo)". When I'm in a non-login shell the minimum shell level (echo $SHLVL) starts at minimum level 2 and increases with successive sub-shells. But when I'm using a login-shell, the minimum shell level (echo $SHLVL) starts at minimum shell level 2 and increases with successive sub-shells.

[Que.] Why is there a difference in minimum shell level between login shell (starts at minimum shell level 1) and non-login shell (starts at minimum shell level 2)? enter image description here

I'm using bash.

  • 1
    Don't post screenshots of text, paste the actual text... – jasonwryan Jan 12 '18 at 7:16
  • 1
    @jasonwryan - actually, in this case it helps to see that the poster is talking about a shell in a GUI terminal – chexum Jan 12 '18 at 7:20
  • Then probably the OP should post both. – Weijun Zhou Jan 12 '18 at 7:24
  • 1
    @chexum It's just text: the screenshot is entirely unnecessary. – jasonwryan Jan 12 '18 at 7:47
2

From the bash man page:

SHLVL Incremented by one each time an instance of bash is started.

As you see, this variable is unrelated to the fact whether it is a login shell or not. It just means that your bash shell has been started by another bash shell. Since we don't know what exactly you are doing to get your shell, I can't say why you have a nested shell invocation, but here are a few common cases:

  • You are starting a new terminal window from the command line

  • You are using some OS feature to start a new terminal window, and this feature is implemented by starting a bash first which then runs the terminal which then in turn runs a new shell

  • You have a recursive bash call in your .bash_profile which is run whenever SHLVL equals 1 (this sounds weird, but I have seen this already twice!)

  • The questioner is running su with the -l option. – JdeBP Jan 12 '18 at 13:33
1

When you log in to your GUI session, the script that sets up your session is executed in a non-interactive login shell. It reads /etc/profile, your ~/.[bash_]profile etc. and sets up your environment for the whole GUI session. Then the shell executes a script that will start your desktop environment. Effectively, that shell will be SHLVL 1 for your session.

The X session setup script may actually exec the last command that actually fires up the desktop environment. That explains why you can't find a shell process in the process tree view for your session (ps xf): that shell is done its job and gone, only its environment variables (and any other inheritable settings, like custom ulimits) are inherited by the main process of the desktop environment, which passes them on to all its child processes. This way, a program started from a desktop menu will also have any environment variables you may have set in your .bash_profile, and so will work as you'll expect.

It is also possible to set up the terminal windows to start up as login shells, so they would be SHLVL 1. At least KDE on Debian seems to do it that way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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