Setting an environment variable on same line as program execution is different than setting it separately? - shell variables vs. environment variables

Question

What is the difference between:

prompt$   TSAN_OPTIONS=\"suppressions=/somewhere/file\" ./myprogram

and

prompt$   TSAN_OPTI         


        

Answer 1

To complement Etan Reisner's helpful answer:

It's important to distinguish between shell variables and environment variables:

^{Note: The following applies to all POSIX-compatible shells; bash-specific extensions are marked as such.}

A shell variable is a shell-specific construct that is limited to the shell that defines it (with the exception of subshells, which get their own copies of the current shell's variables),
whereas an environment variable is inherited by any child process created by the current process (shell), whether that child process is itself a shell or not.
Note that all-uppercase variable names should only be used for environment variables.

^{Either way, a child process only ever inherits copies of variables, whose modification (by the child) does not affect the parent.}

• All environment variables are also shell variables (the shell ensures that),
• but the inverse is NOT true: shell variables are NOT environment variables, unless explicitly designated or inherited as such - this designation is called exporting.
  • note that the off-by-default -a shell option (set with set -a, or passed to the shell itself as a command-line option) can be used to auto-export all shell variables.

Thus,

• any variables you create implicitly by assignment - e.g., TSAN_OPTIONS="suppressions=/somewhere/file" - are ONLY shell variables, but NOT ALSO environment variables,
• EXCEPT - perhaps confusingly - when prepended directly to a command - e.g. TSAN_OPTIONS="suppressions=/somewhere/file" ./myprogram - in which case they are ONLY environment variables, only in effect for THAT COMMAND.
  • This is what Etan's answer describes.

---

Shell variables become environment variables as well under the following circumstances:

• based on environment variables that the shell itself inherited, such as $HOME
• shell variables created explicitly with export varName[=value] or, in bash, also with declare -x varName[=value]
  • by contrast, in bash, using declare without -x, or using local in a function, creates mere shell variables
• shell variables created implicitly while the off-by-default -a shell option is in effect (with limited exceptions)

Once a shell variable is marked as exported - i.e., marked as an environment variable - any subsequent changes to the shell variable update the environment variable as well; e.g.:

export TSAN_OPTIONS  # creates shell variable *and* corresponding environment variable

# ...

TSAN_OPTIONS="suppressions=/somewhere/file" # updates *both* the shell and env. var.

---

• export -p prints all environment variables
• unset [-v] MYVAR undefines shell variable $MYVAR and also removes it as an environment variable, if applicable.
• in bash:
  • You can "unexport" a given variable without also undefining it as a shell variable with export -n MYVAR - this removes MYVAR from the environment, but retains its current value as a shell variable.
  • declare -p MYVAR prints variable $MYVAR's current value along with its attributes; if the output starts with declare -x, $MYVAR is exported (is an environment variable)