Classic Shell Scripting - Arnold Robbins [215]
Korn Shell Startup
Like the Bourne shell, the Korn shell, ksh, reads /etc/profile and $HOME/.profile, if they exist and are readable, when it starts as a login shell.
When ksh93 starts as an interactive shell (either login or nonlogin), it then does the equivalent of:
test -n "$ENV" && eval . "$ENV" Try to read $ENV
ksh88 does the $ENV processing unconditionally, for all shells.
The eval command is described in Section 7.8. For now, it is enough to know that it first evaluates its arguments so that any variables there are expanded, and then executes the resulting string as a command. The effect is that the file named by ENV is read and executed in the context of the current shell. The PATH directories are not searched for the file, so ENV should generally specify an absolute pathname.
The ENV feature solves the problem that the Bourne shell has in setting up private aliases for child shell sessions. However, it does not solve the customization problem for nonlogin remote sessions: their shells never read any initialization files.
Like the Bourne shell, a noninteractive ksh93 shell does not read any startup scripts, nor does it read any termination scripts just before it exits, unless you issue a suitable trap command. (As we said before, even a noninteractive ksh88 reads and executes the $ENV file at startup.)
Bourne-Again Shell Startup and Termination
While GNU bash is often used as a login shell in its own right, it can also masquerade as the Bourne shell when it is invoked with the name sh. It then behaves on startup largely as described in Section 14.7.1, in which case most of the rest of this section does not apply. On GNU/Linux systems, /bin/sh is invariably a symbolic link to /bin/bash.
* * *
Warning
The bash emulation of the Bourne shell is not perfect because bash hides only some of its many extensions when invoked as sh. We have occasionally found shell scripts in software packages that were developed in a GNU/Linux environment for execution by /bin/sh, but were not tested in real Bourne shell environments, where they fail because of their use of extended features.
* * *
When bash is a login shell, on startup it does the equivalent of:
test -r /etc/profile && . /etc/profile Try to read /etc/profile
if test -r $HOME/.bash_profile ; then Try three more possibilities
. $HOME/.bash_profile
elif test -r $HOME/.bash_login ; then
. $HOME/.bash_login
elif test -r $HOME/.profile ; then
. $HOME/.profile
fi
The system-wide file is the same as for the Bourne shell, but the search order in $HOME allows you to put bash-specific initializations in either of two files. Otherwise, bash falls back to reading your personal Bourne-shell startup file.
On exit, a bash login shell effectively does this:
test -r $HOME/.bash_logout && . $HOME/.bash_logout Try to read a termination script
Unlike the Bourne shell, bash reads an initialization file on startup when it is an interactive nonlogin shell, by steps equivalent to this:
test -r $HOME/.bashrc && . $HOME/.bashrc Try to read $HOME/.bashrc
In this case, login-shell startup files are not read.
When bash is used noninteractively, instead of reading a .bashrc file or login-shell startup files, it reads a file defined by the BASH_ENV variable, like this:
test -r "$BASH_ENV" && eval . "$BASH_ENV" Try to read $BASH_ENV
As with ksh, the PATH directories are not searched for this file.
Notice the difference: the Korn shell's ENV variable is used only for nonlogin interactive shells, whereas bash's BASH_ENV is used only for noninteractive shells.
To clarify the startup-file processing order, we fitted each of them with an echo command. A login session then looks like this:
$ login
Start