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?
Asked
Active
Viewed 60 times
1 Answers
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.
