5

Shells can be login as those run by the text console and non-login as those run by Gnome Terminal. Why is this complexity needed? Why can't a login shell follow the same rules as the non-login?

muru
  • 197,895
  • 55
  • 485
  • 740
Bojan Landekić
  • 81
  • just guessing, but to tell how many programs to kill when you logout? – Xen2050 Apr 01 '16 at 17:08
  • Graphical sessioons also have processes that need killing and arent tied to the login shell. – Bojan Landekić Apr 01 '16 at 17:14
  • Logically thinking about this, user needs access to the system somehow , so there must be a login point, hence there must be a login shell. GUI is one of the entry points. Every shell that spawns after the login - doesn't need to be authenticated , the user already has access to the system, so it wouldn't make sense to have login shell ask for login again. – Sergiy Kolodyazhnyy Apr 01 '16 at 22:42
  • I understand Serg and thank you for clarifying the need for non-authenticating shell (non-login). But are the env/configs different for login and non-login shells? If so why? – Bojan Landekić Apr 02 '16 at 02:08
  • FYI (maybe OT?) running ps auxf or just ps axf shows you an "ASCII art process hierarchy (forest)" and looking at the "branches" of the "tree" under the window manager (if you're logged into a gui) shows what would be killed when you log out of the gui - like "cutting off the branch" (I think) – Xen2050 Apr 02 '16 at 09:40
  • This Super User post has a good reasoning. – muru Apr 03 '16 at 14:32

1 Answers1

1

First, have a look at this answer to understand the differences between login and non-login shells. Basically, they read different initialization files. Now, many distributions—including Debian and, by extension, Ubuntu—are actually moving towards what you describe. On these distributions, the default ~/.profile or ~/.bash_profile files contain something like the following:

[[ -f ~/.bashrc ]] && . ~/.bashrc

That means that login shells—which read ~/.profile—will also read ~/.bashrc, making them behave like non-login interactive shells. Or, rather, making them have the same setup as non-login interactive shells in addition to whatever is set up for login shells.

There are, however, perfectly good reasons to have the two behave differently. For example, it is very common to have a machine that you access either by sitting down in front of it and running a graphical session or remotely, through ssh. In the later case, you would be running a login shell and in the former, you would be opening terminals running non-login shells.

In such cases, you may want the non-GUI shells to behave differently. For example, for many years, I had this command in my ~/.bashrc file to disable the audible bell:

xset b off

Since my .bashrc was only read by interactive, non-login shells, and those were never run graphically, it was an easy way to disable the bell. However, since my distro switched to having ~/.profile source ~/.bashrc, the command was also being executed when I was logging in through ssh, in a non-GUI environment and, since xset requires a running X session, it produced an error.

More generally, it is often useful to have login shells behave differently since they are usually used for a different purpose. There may be variables you only want set in one type and not the other, or files you only want read. It is, admittedly, less useful to separate the two on a single user home computer, but consider that Linux was for many years primarily aimed at the server market and having multi user systems is very normal. In such cases, the added complexity is worth it since it enables you to have fine grained control over how different types of shells behave.

Community
  • 1
terdon
  • 100,812
  • So can we say the main obstacle that prevents login and non-login shells to behave the same is X window? – Bruce Sun Jul 11 '17 at 03:06
  • @BruceSun no, not really. I should have made that clearer. That's just an easy example to illustrate the general point: that there are cases where you want the shell to behave differently depending on how it was invoked. – terdon Jul 11 '17 at 08:27