A login shell is the first process that executes under your user ID when you log in for an interactive session. The login process tells the shell to behave as a login shell with a convention: passing argument 0, which is normally the name of the shell executable, with a
- character prepended (e.g.
-bash whereas it would normally be
bash. Login shells typically read a file that does things like setting environment variables:
~/.profile for the traditional Bourne shell,
~/.bash_profile additionally for bash†,
~/.zprofile for zsh†,
~/.login for csh, etc.
When you log in on a text console, or through SSH, or with
su -, you get an interactive login shell. When you log in in graphical mode (on an X display manager), you don’t get a login shell, instead you get a session manager or a window manager.
It’s rare to run a non-interactive login shell, but some X settings do that when you log in with a display manager, so as to arrange to read the profile files. Other settings (this depends on the distribution and on the display manager) read
~/.profile explicitly, or don’t read them. Another way to get a non-interactive login shell is to log in remotely with a command passed through standard input which is not a terminal, e.g.
ssh example.com <my-script-which-is-stored-locally (as opposed to
ssh example.com my-script-which-is-on-the-remote-machine, which runs a non-interactive, non-login shell).
When you start a shell in a terminal in an existing session (screen, X terminal, Emacs terminal buffer, a shell inside another, etc.), you get an interactive, non-login shell. That shell might read a shell configuration file (
~/.bashrc for bash invoked as
~/.zshrc for zsh,
~/.cshrc for csh, the file indicated by the
ENV variable for POSIX/XSI-compliant shells such as dash, ksh, and bash when invoked as
$ENV if set and
~/.mkshrc for mksh, etc.).
When a shell runs a script or a command passed on its command line, it’s a non-interactive, non-login shell. Such shells run all the time: it’s very common that when a program calls another program, it really runs a tiny script in a shell to invoke that other program. Some shells read a startup file in this case (bash runs the file indicated by the
BASH_ENV variable, zsh runs
~/.zshenv), but this is risky: the shell can be invoked in all sorts of contexts, and there’s hardly anything you can do that might not break something.
† I’m simplifying a little, see the manual for the gory details.
To tell if you are in a login shell:
prompt> echo $0 -bash # "-" is the first character. Therefore, this is a login shell. prompt> echo $0 bash # "-" is NOT the first character. This is NOT a login shell.
In Bash, you can also use
prompt> shopt login_shell login_shell off
on in a login shell).
Information can be found in
man bash (search for Invocation). Here is an excerpt:
A login shell is one whose first character of argument zero is a -, or
one started with the –login option.
You can test this yourself. Anytime you SSH, you are using a login shell. For Example:
prompt> ssh user@localhost user@localhost's password: prompt> echo $0 -bash
The importance of using a login shell is that any settings in
/home/user/.bash_profile will get executed. Here is a little more information if you are interested (from
“When bash is invoked as an interactive login shell, or as a
non-interactive shell with the –login option, it first reads and
executes commands from the file /etc/profile, if that file exists.
After reading that file, it looks for
~/.profile, in that order, and reads and
executes commands from the first one that exists and is readable. The
–noprofile option may be used when the shell is started to inhibit this behavior.”
In a login shell,
argv == '-'.
This is how it knows it’s a login shell.
And then in some situations it behaves differently depending on its “login shell” status. E.g. a shell, that is not a login shell, would not execute a “logout” command.