Defining a variable with or without export

Questions : Defining a variable with or without export

What is export for?

What is the difference between:

export name=value 

and

name=value 

Total Answers: 15 Answers 15


Popular Answers:

  1. export makes the variable available to sub-processes.

    That is,

    export name=value 

    means that the variable name is available to any process you run from that shell process. If you want a process to make use of this variable, use export, and run the process from that shell.

    name=value 

    means the variable scope is restricted to the shell, and is not available to any other process. You would use this for (say) loop variables, temporary variables etc.

    It’s important to note that exporting a variable doesn’t make it available to parent processes. That is, specifying and exporting a variable in a spawned process doesn’t make it available in the process that launched it.

  2. This answer is wrong but retained for historical purposes. See 2nd edit below.

    Others have answered that export makes the variable available to subshells, and that is correct but merely a side effect. When you export a variable, it puts that variable in the environment of the current shell (ie the shell calls putenv(3) or setenv(3)).
    The environment of a process is inherited across exec, making the variable visible in subshells.

    Edit (with 5 year’s perspective): This is a silly answer. The purpose of ‘export’ is to make variables “be in the environment of subsequently executed commands”, whether those commands be subshells or subprocesses. A naive implementation would be to simply put the variable in the environment of the shell, but this would make it impossible to implement export -p.

    2nd Edit (with another 5 years in passing). This answer is just bizarre. Perhaps I had some reason at one point to claim that bash puts the exported variable into its own environment, but those reasons were not given here and are now lost to history. See Exporting a function local variable to the environment.

  3. export NAME=value for settings and variables that have meaning to a subprocess.

    NAME=value for temporary or loop variables private to the current shell process.

    In more detail, export marks the variable name in the environment that copies to a subprocesses and their subprocesses upon creation. No name or value is ever copied back from the subprocess.

    • A common error is to place a space around the equal sign:

      $ export FOO = "bar" bash: export: `=': not a valid identifier 
    • Only the exported variable (B) is seen by the subprocess:

      $ A="Alice"; export B="Bob"; echo "echo A is $A. B is $B" | bash A is . B is Bob 
    • Changes in the subprocess do not change the main shell:

      $ export B="Bob"; echo 'B="Banana"' | bash; echo $B Bob 
    • Variables marked for export have values copied when the subprocess is created:

      $ export B="Bob"; echo '(sleep 30; echo "Subprocess 1 has B=$B")' | bash & [1] 3306 $ B="Banana"; echo '(sleep 30; echo "Subprocess 2 has B=$B")' | bash Subprocess 1 has B=Bob Subprocess 2 has B=Banana [1]+ Done echo '(sleep 30; echo "Subprocess 1 has B=$B")' | bash 
    • Only exported variables become part of the environment (man environ):

       $ ALICE="Alice"; export BOB="Bob"; env | grep "ALICE|BOB" BOB=Bob 

    So, now it should be as clear as is the summer’s sun! Thanks to Brain Agnew, alexp, and William Prusell.

  4. It should be noted that you can export a variable and later change the value. The variable’s changed value will be available to child processes. Once export has been set for a variable you must do export -n <var> to remove the property.

    $ K=1 $ export K $ K=2 $ bash -c 'echo ${K-unset}' 2 $ export -n K $ bash -c 'echo ${K-unset}' unset 
  5. export will make the variable available to all shells forked from the current shell.

  6. As you might already know, UNIX allows processes to have a set of environment variables, which are key/value pairs, both key and value being strings. Operating system is responsible for keeping these pairs for each process separately.

    Program can access its environment variables through this UNIX API:

    • char *getenv(const char *name);
    • int setenv(const char *name, const char *value, int override);
    • int unsetenv(const char *name);

    Processes also inherit environment variables from parent processes. Operating system is responsible for creating a copy of all “envars” at the moment the child process is created.

    Bash, among other shells, is capable of setting its environment variables on user request. This is what export exists for.

    export is a Bash command to set environment variable for Bash. All variables set with this command would be inherited by all processes that this Bash would create.

    More on Environment in Bash

    Another kind of variable in Bash is internal variable. Since Bash is not just interactive shell, it is in fact a script interpreter, as any other interpreter (e.g. Python) it is capable of keeping its own set of variables. It should be mentioned that Bash (unlike Python) supports only string variables.

    Notation for defining Bash variables is name=value. These variables stay inside Bash and have nothing to do with environment variables kept by operating system.

    More on Shell Parameters (including variables)

    Also worth noting that, according to Bash reference manual:

    The environment for any simple command or function may be augmented temporarily by prefixing it with parameter assignments, as described in Shell Parameters. These assignment statements affect only the environment seen by that command.


    To sum things up:

    • export is used to set environment variable in operating system. This variable will be available to all child processes created by current Bash process ever after.
    • Bash variable notation (name=value) is used to set local variables available only to current process of bash
    • Bash variable notation prefixing another command creates environment variable only for scope of that command.
  7. The accepted answer implies this, but I’d like to make explicit the connection to shell builtins:

    As mentioned already, export will make a variable available to both the shell and children. If export is not used, the variable will only be available in the shell, and only shell builtins can access it.

    That is,

    tango=3 env | grep tango # prints nothing, since env is a child process set | grep tango # prints tango=3 - "type set" shows `set` is a shell builtin 
  8. Two of the creators of UNIX, Brian Kernighan and Rob Pike, explain this in their book “The UNIX Programming Environment”. Google for the title and you’ll easily find a pdf version.

    They address shell variables in section 3.6, and focus on the use of the export command at the end of that section:

    When you want to make the value of a variable accessible in sub-shells, the shell’s export command should be used. (You might think about why there is no way to export the value of a variable from a sub-shell to its parent).

  9. Here’s yet another example:

    VARTEST="value of VARTEST" #export VARTEST="value of VARTEST"  sudo env | grep -i vartest sudo echo ${SUDO_USER} ${SUDO_UID}:${SUDO_GID} "${VARTEST}" sudo bash -c 'echo ${SUDO_USER} ${SUDO_UID}:${SUDO_GID} "${VARTEST}"' 

    Only by using export VARTEST the value of VARTEST is available in sudo bash -c ‘…’!

    For further examples see:

  10. Just to show the difference between an exported variable being in the environment (env) and a non-exported variable not being in the environment:

    If I do this:

    $ MYNAME=Fred $ export OURNAME=Jim 

    then only $OURNAME appears in the env. The variable $MYNAME is not in the env.

    $ env | grep NAME OURNAME=Jim 

    but the variable $MYNAME does exist in the shell

    $ echo $MYNAME Fred 
  11. By default, variables created within a script are only available to the current shell; child processes (sub-shells) will not have access to values that have been set or modified. Allowing child processes to see the values, requires use of the export command.

  12. Although not explicitly mentioned in the discussion, it is NOT necessary to use export when spawning a subshell from inside bash since all the variables are copied into the child process.

  13. As yet another corollary to the existing answers here, let’s rephrase the problem statement.

    The answer to “should I export” is identical to the answer to the question “Does your subsequent code run a command which implicitly accesses this variable?”

    For a properly documented standard utility, the answer to this can be found in the ENVIRONMENT section of the utility’s man page. So, for example, the git manual page mentions that GIT_PAGER controls which utility is used to browse multi-page output from git. Hence,

    # XXX FIXME: buggy branch="main" GIT_PAGER="less" git log -n 25 --oneline "$branch" git log "$branch" 

    will not work correctly, because you did not export GIT_PAGER. (Of course, if your system already declared the variable as exported somewhere else, the bug is not reproducible.)

    We are explicitly referring to the variable $branch, and the git program code doesn’t refer to a system variable branch anywhere (as also suggested by the fact that its name is written in lower case; but many beginners erroneously use upper case for their private variables, too! See Correct Bash and shell script variable capitalization for a discussion) so there is no reason to export branch.

    The correct code would look like

    branch="main" export GIT_PAGER="less" git log -n 25 --oneline "$branch" git log -p "$branch" 

    (or equivalently, you can explicitly prefix each invocation of git with the temporary assignment

    branch="main" GIT_PAGER="less" git log -n 25 --oneline "$branch" GIT_PAGER="less" git log -p "$branch" 

    In case it’s not obvious, the shell script syntax

    var=value command arguments 

    temporarily sets var to value for the duration of the execution of

    command arguments 

    and exports it to the command subprocess, and then afterwards, reverts it back to the previous value, which could be undefined, or defined with a different – possibly empty – value, and unexported if that’s what it was before.)

    For internal, ad-hoc or otherwise poorly documented tools, you simply have to know whether they silently inspect their environment. This is rarely important in practice, outside of a few specific use cases, such as passing a password or authentication token or other secret information to a process running in some sort of container or isolated environment.

    If you really need to know, and have access to the source code, look for code which uses the getenv system call (or on Windows, with my condolences, variations like getenv_s, w_getenv, etc). For some scripting languages (such as Perl or Ruby), look for ENV. For Python, look for os.environ (but notice also that e.g. from os import environ as foo means that foo is now an alias for os.environ). In Node, look for process.env. For C and related languages, look for envp (but this is just a convention for what to call the optional third argument to main, after argc and argv; the language lets you call them anything you like). For shell scripts (as briefly mentioned above), perhaps look for variables with uppercase or occasionally mixed-case names, or usage of the utility env. Many informal scripts have undocumented but discoverable assignments usually near the beginning of the script; in particular, look for the ?= default assignment parameter expansion.

    For a brief demo, here is a shell script which invokes a Python script which looks for $NICKNAME, and falls back to a default value if it’s unset.

    #!/bin/sh NICKNAME="Handsome Guy" demo () { python3 <<____ from os import environ as env print("Hello, %s" % env.get("NICKNAME", "Anonymous Coward")) ____ } demo # prints "Hello, Anonymous Coward" # Fix: forgot export export NICKNAME demo # prints "Hello, Handsome Guy" 

    As another tangential remark, let me reiterate that you only ever need to export a variable once. Many beginners cargo-cult code like

    # XXX FIXME: redundant exports export PATH="$HOME/bin:$PATH" export PATH="/opt/acme/bin:$PATH" 

    but typically, your operating system has already declared PATH as exported, so this is better written

    PATH="$HOME/bin:$PATH" PATH="/opt/acme/bin:$PATH" 

    or perhaps refactored to something like

    for p in "$HOME/bin" "/opt/acme/bin" do case :$PATH: in *:"$p":*) ;; *) PATH="$p:$PATH";; esac done # Avoid polluting the variable namespace of your interactive shell unset p 

    which avoids adding duplicate entries to your PATH.

    1. git stash

    2. git branch -d the_local_branch

    3. git checkout -t <name of remote>

    4. git stash apply

    This worked for me..!!

  14. Use this command to abort a merge:

    git merge –abort

  15. If you notice that you need to revert immediately after the merge and you haven’t done anything else after the merge attempt, you can just issue this command: git reset --hard [email protected]{1}.

    Essentially, your merge sha will be pointing to [email protected]{0} if nothing else was committed after the merge and so [email protected]{1} will be the previous point before the merge.

  16. In this case, you will want to reset your branch with git reset --hard <branch_name>. If you want to save your changes before reseting them be sure to create a new branch and git checkout <branch_name>.

    You can reset the state to a specific commit with git reset --hard <commit_id> as well.

    If the changes have been pushed you can use git revert <branch_name> instead. Be sure to check out how to use git revert and git checkout in other scenarios as well.

Tasg: linux, bash