Return to Answer

That would have been another matter. Here, we're passing var=value to the sh command, and sh does happen to use its environment. Shells convert each of the variables they receive from their environment to a shell variable, so the var environment variable sh receives will be converted to a $var variable, and when it expands it in that echo command line, that will become echo value. Because the environment is by default inherited, echo will also receive var=value in its environment (or would if it were executed), but again, echo doesn't care about the environment.

^{¹ Stricktly speaking, that's not completely true. Several implementations will care about the localisation environment variables (LANG, LOCPATH, LC_*...), the GNU implementation cares about the POSIXLY_CORRECT environment variable (compare env echo --version with env POSIXLY_CORRECT=1 echo --version on a GNU system).}

That would have been another matter. Here, we're passing var=value to the sh command, and sh does happen to use its environment. Shells convert each² of the variables they receive from their environment to a shell variable, so the var environment variable sh receives will be converted to a $var variable, and when it expands it in that echo command line, that will become echo value. Because the environment is by default inherited, echo will also receive var=value in its environment (or would if it were executed), but again, echo doesn't care about the environment.

^{¹ Stricktly speaking, that's not completely true. Several implementations will care about the localisation environment variables (LANG, LOCPATH, LC_*...), the GNU implementation cares about the POSIXLY_CORRECT environment variable (compare env echo --version with env POSIXLY_CORRECT=1 echo --version on a GNU system).}

^{² well only (some of) the ones that are valid variable names in the syntax of the particular shell. For instance env ++=foo 1x=bar 3=qwe '#=rty' IFS=asd é=x sh -c 'shell code' will not create ++, 1x, 3, # shell variables as those are not valid variable names (though # and 3 are non-variable shell parameters), and don't import IFS from the environment as that would be source of security vulnerabilities; for é, YMMV.}

With mksh (and soon zsh), you can abuse the ${|cmd} construct which can also have a local scope and will expand to nothing as long as you don't set $REPLY within:

${|local var=value; echo "$var"}; echo "$value"

With mksh (and soon zsh), you can abuse the ${|cmd} construct which can also have a local scope making sure it expands to nothing by making sure you don't set $REPLY within:

${|local var=value; echo "$var"}; echo "$var"

With zsh, you can use anonymous functions which are designed for that:

begin
  set -l var value
  echo 1: $var
end
echo 2: $var

^{¹ Stricktly speaking, that's not completely true. Several implementations will care about the localisation environment variables (LANG, LOCPATH, LC_*...), the GNU implementation cares about the POSIXLY_CORRECT environment variable (compare env echo --version with POSIXLY_CORRECT=1 env echo --version on a GNU system).}

With zsh, you can use anonymous functions which like normal functions can have a local scope:

begin
  set -l var value
  echo 1: $var
end
echo 2: $var

With mksh (and soon zsh), you can abuse the ${|cmd} construct which can also have a local scope and will expand to nothing as long as you don't set $REPLY within:

${|local var=value; echo "$var"}; echo "$value"

^{¹ Stricktly speaking, that's not completely true. Several implementations will care about the localisation environment variables (LANG, LOCPATH, LC_*...), the GNU implementation cares about the POSIXLY_CORRECT environment variable (compare env echo --version with env POSIXLY_CORRECT=1 echo --version on a GNU system).}