Bashrc, Env, and Export – Understanding Environment Variables in Bash

bashbashrcenvironment-variablesshellterminal

Disclaimer: Using bash.

I just need some confirmation / correction on my understanding of these things:

env is basically displaying the current environmental variables that are accessible to my current session AND any child sessions (such as if I were to bash into a child session).
If I were to set a new variable such as MYMESSAGE="hello world!" then it would only be visible to the session in which I created it. If I went into a child session, I would not be able to, for example, echo $MYMESSAGE.
I can export MYMESSAGE="hello world!" though to make it accessible to child sessions. export is the same as adding it to whatever env is pulling up.
However, just because you export something, it won't stick if you happen to close out your sessions and restart the terminal. Edit .bashrc in your /home/username/ directory and add any new environmental variables there, since this script is run on login.

Is my understanding correct so far?

Furthermore, I don't fully understand where the details of env comes from. Is the list of environmental variables all stored in some file and then edited/appended to by .bashrc? I'm just trying to understand how all of this works.

Best Answer

You basically got it right, however a few extra points...

There are several "start-up files" bash may run - some for backwards compatibility with the bourne-shell (sh), other depending on how you started bash: Did you log-in to X? Did you log-in to a TTY? Did you start bash in another (bash-)shell? Is bash running as a script (non-interactive)? Thus .bashrc is not always run, nor may it be the only start-up file. However, it's a good idea to "source" (read and execute) .bashrc in the other start-up files too, so the content of your .bashrc is always added. Use man bash and look especially on the part about how bash starts... the FILES-section also list the files bash uses, including all start-up files. For a more in-depth, try info bash.

In addition to you own start-up files, there are corresponding "default" global start-up files in /etc - these are typically read/executed by bash before your own start-up files. There also other programs that defines their own environment-variables in addition to those defined by bash,which may complement or even override those set by bash. Of particular note is X (the GUI), since it will set-up two different sets of environments, depending on whether X is started manually (with xinit or startx) from a VT, or is started by a "display manager" (eg. xdm or kdm) so you can log-in directly into X (X is started when you boot, and you got a dialog-box for username/password in X).

But before bash, X or any other programs starts, much of the environment - environment-variables - you'll be using, will have been set-up, for example by the login command. Much of this you can find in /etc/login.defs and other configuration-files. For example, the PATH-variable will be set-up - and will differ depending on whether you're root or a normal user.

So if you look at the various files and scripts that are ran as part of the boot, init and log-in process; you'll find most of all the variables you can list with env. Some however - like CWD (current working directory) - are set (and updated) automatically by the shell (bash) itself.

When you run a command, what happen is that bash use a system call called fork(). bash basically makes an identical copy of itself, with the exception that the child gets a new PID (Process ID) and that it's PPID (Parent PID) is that of it's "mother". Else they're identical - even including the environment-variables... assuming the variable in question was made inheritable by first exporting it. You now got two copies of bash. Then another system-call -exec() - is used, which basically replaces the bash-program "in memory" for the child bash-process, with another program - for example with ls, ps or mutt (whatever you typed)... but the environment-variables remains, so the new program inherits it's environment from bash. This child now controls your terminal (unless you put the command in the background with &) until it terminates, while your original bash-shell (basically) sleeps. When the command terminates, you return to your original bash-shell, which is ready for another command.

Related Solutions

Using Export in .bashrc – How to Set Environment Variables in Bash

You only need export for variables that should be "seen" by other programs which you launch in the shell, while the ones that are only used inside the shell itself don't need to be exported.

This is what the man page says:

The  supplied  names are marked for automatic export to the environ‐
ment of subsequently executed commands.  If the -f option is  given,
the  names  refer to functions.  If no names are given, or if the -p
option is supplied, a list of all names that are  exported  in  this
shell  is  printed.   The -n option causes the export property to be
removed from each name.  If a variable name is  followed  by  =word,
the  value  of  the variable is set to word.  export returns an exit
status of 0 unless an invalid option  is  encountered,  one  of  the
names  is  not a valid shell variable name, or -f is supplied with a
name that is not a function.

This can be demonstrated with the following:

$ MYVAR="value"
$ echo ${MYVAR}
value
$ echo 'echo ${MYVAR}' > echo.sh
$ chmod +x echo.sh
$ ./echo.sh

$ export MYVAR="value-exported"
$ ./echo.sh
value-exported

Explanation:

I first set ${MYVAR} to be a Shell variable with MYVAR="value". Using echo I can echo the value of it because echo is part of the shell.
Then I create echo.sh. That's a little script that basically does the same, it just echoes ${MYVAR}, but the difference is that it will run in a different process because it's a separate script.
When calling echo.sh it outputs nothing, because the new process does not inherit ${MYVAR}
Then I export ${MYVAR} into my environment with the export keyword
When I now run the same echo.sh again, it echoes the content of ${MYVAR} because it gets it from the environment

So to answer your question:

It depends where a variable is going to be used, whether you have to export it or not.

Bash – the difference between env, setenv, export and when to use

export VARIABLE_NAME='some value' is the way to set an environment variable in any POSIX-compliant shell (sh, dash, bash, ksh, etc.; also zsh). If the variable already has a value, you can use export VARIABLE_NAME to make it an environment variable without changing its value.

Pre-POSIX Bourne shells did not support this, which is why you'll see scripts that avoid export VARIABLE_NAME='some value' and use VARIABLE_NAME='some value'; export VARIABLE_NAME instead. But pre-POSIX Bourne shells are extremely rare nowadays.

setenv VARIABLE_NAME='some value' is the csh syntax to set an environment variable. setenv does not exist in sh, and csh is extremely rarely used in scripts and has been surpassed by bash for interactive use for the last 20 years (and zsh for even longer), so you can forget about it unless you encounter it.

The env command is very rarely useful except in shebang lines. When invoked without arguments, it displays the environment, but export does it better (sorted, and often quoted to disambiguate newlines in values from newlines that separate values). When invoked with arguments, it runs a command with extra environment variables, but the same command without env also works (VAR=value mycommand runs mycommand with VAR set to value, just like env VAR=value mycommand). The reason env is useful in shebang line is that it performs PATH lookup, and it happens to not do anything else when invoked with a command name. The env command can be useful to run a command with only a few environment variables with -i, or without parameters to display the environment including variables with invalid names that the shell doesn't import.

Best Answer

Related Solutions

Using Export in .bashrc – How to Set Environment Variables in Bash

Bash – the difference between env, setenv, export and when to use

Related Question