Environment Variables – What Scopes Can Shell Variables Have?

environment-variables

I just ran into a problem that shows me I'm not clear on the scope of shell variables.

I was trying to use bundle install, which is a Ruby command that uses the value of $GEM_HOME to do its work. I had set $GEM_HOME, but the command ignored that value until I used export, as in export GEM_HOME=/some/path.

I read that this makes the variable somehow "global" (also known as an environment variable), but I don't understand what that means. I know about globals in programming, but not across distinct programs.

Also, given that my setting such variables applies only to the current shell session, how would I set them for, say, a daemonized process?

What scopes can shell variables have?

Best Answer

The processes are organized as a tree: every process has a unique parent, apart from init which PID is always 1 and has no parent.

The creation of a new process goes generally through a pair of fork/execv system calls, where the environment of the child process is a copy of the parent process.

To put a variable in the environment from the shell you have to export that variable, so that it is visible recursively to all children. But be aware that if a child change the value of a variable, the changed value is only visible to it and all processes created after that change (being a copy, as previously said).

Take also into account that a child process could change its environment, for example could reset it to default values, as is probably done from login for example.

Related Solutions

Shell – how to share environment variables between shells like globals related to a master pid

You can write the environment to a file with export -p and read it back periodically in the other instances with . (the include command). But as you note, if there are concurrent modifications, the result won't be pretty.

If you want modifications to propagate instantly, you'll have to use a wrapper around the export builtin that also propagates the changes to the other shells. On Linux, you can use the flock utility.

global_export () {
  {
    flock 0
    . /path/to/env
    [ $# -eq 0 ] || export "$@"
    export -p >/path/to/env
  } </path/to/env
}

Note that you'll need to call global_export whenever you assign a new value to an exported variable.

This is rather clumsy. It's likely that there's a better way to solve your problem. The most obvious way is to have whatever command is using those environment variable read a configuration files instead.

Bash – How to pass environment variables to a non-interactive shell (with example)

If it is an sh script - as in, it explicitly references #!/bin/sh - which might still be bash but would be like invoking it with --posix --no-rc --no-profile - then you can specify the ENV file with the ENV environment variable:

ENV=/path/to/rcfile sh

Specific variables need either to be declared on the command-line - as above for $ENV - or else with export. For example, for $PATH you do:

export "PATH=$PATH:/some/more/paths"; sh

The $BASH_ENV variable you reference is not a file you need to source - and it isn't interpreted anyway when bash is invoked as sh - but is rather a path to a file that is sourced when a non-interactive bash shell is invoked - such as with a script that specifies the:

#!/bin/bash

...or whatever bang line.

Another way you might like to invoke your script/shell is with the env utility. It can be used to explicitly remove values from the environment, or else, as is usually easiest, to wipe it clean from the start:

env - BASH_ENV=/path/to/rcfile /usr/bin/bash /some/script/file

That will tell env to invoke the /usr/bin/bash command - with all its arguments appended - with the $BASH_ENV environment variable specified, but otherwise with a clean environment entirely.

Best Answer

Related Solutions

Shell – how to share environment variables between shells like globals related to a master pid

Bash – How to pass environment variables to a non-interactive shell (with example)

Related Question