PATH environment variable in linux
The answer to your question can be found in INVOCATION
section of man bash
.
Here's relevant excerpt:
When bash is invoked as an interactive login shell, or as a non-inter-
active shell with the --login option, it first reads and executes com-
mands from the file /etc/profile, if that file exists. After reading
that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.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.
When a login shell exits, bash reads and executes commands from the
file ~/.bash_logout, if it exists.
When an interactive shell that is not a login shell is started, bash
reads and executes commands from ~/.bashrc, if that file exists. This
may be inhibited by using the --norc option. The --rcfile file option
will force bash to read and execute commands from file instead of
~/.bashrc.
When bash is started non-interactively, to run a shell script, for
example, it looks for the variable BASH_ENV in the environment, expands
its value if it appears there, and uses the expanded value as the name
of a file to read and execute. Bash behaves as if the following com-
mand were executed:
if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
but the value of the PATH variable is not used to search for the file
name.
There's even more in the man page, I recommend you read it.
Things are a little more complex than just what your shell provides.
There are three main ways to login:
- login from a true terminal (nowadays, mainly the console)
- login from a pseudo-terminal (mainly network connections)
- login from a graphic environment
They all are able to set up the environment before executing your shell, and they all do (HOME
, LOGNAME
, TERM
are probably not set by your shell, and even if you have no start-up files, your shell usually inherits the PATH
environment variable).
When logging in from a true terminal, the process handling the connection will probably set up the TERM
environment variable and delegate the rest of the work to the login
program. That program does some verifications (such as preventing login for root on insecure terminals), ensures that the whole environment excepted TERM
is clean, initializes HOME
, PATH
, SHELL
, TERM
, MAIL
, and LOGNAME
and then launch your login shell. Your shell will then do its own initialization.
When logging in from a pseudo-terminal, the same things happen with a little twist. Often the environment gets more initialization from the process handling the connection than just the TERM
environment variable (network protocols often have a way to transfer the environment from the other side) and thus login
is used in a mode in which it doesn't clean the environment, the clean up is done by the program handling the connection.
Graphic environments usually don't delegate to login
but behave similarly. After verifying your credentials, they create a clean environment (with usual environment variable and at least DISPLAY
set correctly; they often allow a sysadmin provided script to add things) then launch the start up script for your desktop environment; those may try to get the environment from your login shell and also often provide the possibility to provide a script to complete the set up. So when you launch any program from your desktop, its environment is the combination of what the graphical login program, your desktop environment and your login scripts set.
One last thing: when you launch a terminal emulator, you may get either a login shell (in which case the login script from the shell is executed and thus you get to see the effect of your latest changes in it, but won't see the same environment as the other programs) or not (in which case the login script from the shell isn't executed, you don't see your latest changes, but you get the same environment as the other programs — modified by the interactive initialization script of your shell).