Why can't I specify an environment variable and echo it in the same command line?

Consider this snippet:

$ SOMEVAR=AAA
$ echo zzz $SOMEVAR zzz
zzz AAA zzz

Here I've set $SOMEVAR to AAA on the first line - and when I echo it on the second line, I get the AAA contents as expected.

But then, if I try to specify the variable on the same command line as the echo:

$ SOMEVAR=BBB echo zzz $SOMEVAR zzz
zzz AAA zzz

... I do not get BBB as I expected - I get the old value (AAA).

Is this how things are supposed to be? If so, how come then you can specify variables like LD_PRELOAD=/... program args ... and have it work? What am I missing?

What you see is the expected behaviour. The trouble is that the parent shell evaluates $SOMEVAR on the command line before it invokes the command with the modified environment. You need to get the evaluation of $SOMEVAR deferred until after the environment is set.

Your immediate options include:

1. SOMEVAR=BBB eval echo zzz '$SOMEVAR' zzz.
2. SOMEVAR=BBB sh -c 'echo zzz $SOMEVAR zzz'.

Both these use single quotes to prevent the parent shell from evaluating $SOMEVAR; it is only evaluated after it is set in the environment (temporarily, for the duration of the single command).

Another option is to use the sub-shell notation (as also suggested by Marcus Kuhn in his answer):

(SOMEVAR=BBB; echo zzz $SOMEVAR zzz)

The variable is set only in the sub-shell

The Problem, Revisited

Quite frankly, the manual is confusing on this point. The GNU Bash manual says:

> The environment for any simple command or function [note that this excludes builtins] 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.

If you really parse the sentence, what it's saying is that the environment for the command/function is modified, but not the environment for the parent process. So, this will work:

$ TESTVAR=bbb env | fgrep TESTVAR
TESTVAR=bbb

because the environment for the env command has been modified before it executed. However, this will not work:

$ set -x; TESTVAR=bbb echo aaa $TESTVAR ccc
+ TESTVAR=bbb
+ echo aaa ccc
aaa ccc

because of when parameter expansion is performed by the shell.

Interpreter Steps

Another part of the problem is that Bash defines these steps for its interpreter:

1. Reads its input from a file (see Shell Scripts), from a string supplied as an argument to the -c invocation option (see Invoking Bash), or from the user's terminal.
2. Breaks the input into words and operators, obeying the quoting rules described in Quoting. These tokens are separated by metacharacters. Alias expansion is performed by this step (see Aliases).
3. Parses the tokens into simple and compound commands (see Shell Commands).
4. Performs the various shell expansions (see Shell Expansions), breaking the expanded tokens into lists of filenames (see Filename Expansion) and commands and arguments.
5. Performs any necessary redirections (see Redirections) and removes the redirection operators and their operands from the argument list.
6. Executes the command (see Executing Commands).
7. Optionally waits for the command to complete and collects its exit status (see Exit Status).

What's happening here is that builtins don't get their own execution environment, so they never see the modified environment. In addition, simple commands (e.g. /bin/echo) do get a modified ennvironment (which is why the env example worked) but the shell expansion is taking place in the current environment in step #4.

In other words, you aren't passing 'aaa $TESTVAR ccc' to /bin/echo; you are passing the interpolated string (as expanded in the current environment) to /bin/echo. In this case, since the current environment has no TESTVAR, you are simply passing 'aaa ccc' to the command.

Summary

The documentation could be a lot clearer. Good thing there's Stack Overflow!

See Also

http://www.gnu.org/software/bash/manual/bashref.html#Command-Execution-Environment

To achieve what you want, use

( SOMEVAR=BBB; echo zzz $SOMEVAR zzz )

Reason:

• You must separate the assignment by semicolon or new line from the next command, otherwise it is not executed before parameter expansion happens for the next command (echo).

• You need to make the assignment inside a subshell environment, to make sure it does not persist beyond the current line.

This solution is shorter, neater and more efficient than some of the others suggested, in particular it does not create a new process.

Let's look to http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html">the POSIX specification to understand why this behaves as it does, not just in bash but in any compliant shell:

---

2.10.2, Shell Grammar Rules

From rule 7(b), covering cases where an assignment precedes a simple command:

> If all the characters preceding '=' form a valid name (see the Base Definitions volume of IEEE Std 1003.1-2001, Section 3.230, Name), the token ASSIGNMENT_WORD shall be returned. (Quoted characters cannot participate in forming a valid name.) > > [...] > > Assignment to the NAME shall occur as specified in Simple Commands.

Thus, parsing this assignment is required for a POSIX-compliant shell.

---

2.9.1, Simple Commands

> 3. Redirections shall be performed as described in Redirection. > > 4. Each variable assignment shall be expanded for tilde expansion, parameter expansion, command substitution, arithmetic expansion, and quote removal prior to assigning the value. > > [...] > > If no command name results, variable assignments shall affect the current execution environment. Otherwise, the variable assignments shall be exported for the execution environment of the command and shall not affect the current execution environment (except for special built-ins). If any of the variable assignments attempt to assign a value to a read-only variable, a variable assignment error shall occur. See Consequences of Shell Errors for the consequences of these errors.

Thus: An assignment given in part of the prefix to a simple command must be exported, and must not impact the "current shell environment", unless the command being invoked is a special built-in. Moreover, these steps shall follow redirections, which by nature must occur late in the command invocation process.

---

2.12, Shell Execution Environment

> Utilities other than the special built-ins (see Special Built-In Utilities) shall be invoked in a separate environment that consists of the following. The initial value of these objects shall be the same as that for the parent shell, except as noted below. > > [...] > > Variables with the export attribute, along with those explicitly exported for the duration of the command, shall be passed to the utility environment variables

---

Thus: These variables are expanded by the subshell after fork and before exec'ing the command being invoked, and must -- by specification -- impact the child's environment alone.

---

Now, for some different behavior:

SOMEVAR=BBB sh -c 'echo "$SOMEVAR"'

... benefits from the sh instance creating shell variables from its environment variables (as required in section 2.5.3 of the POSIX specification) on startup.

---

It's worth noting, by the way, that the syntax you're asking about is for assignment within a simple command, as opposed to assignment within a subshell. You can control assignment in a subshell involved in a pipeline like so:

{ SOMEVAR=BBB; echo "$SOMEVAR"; } | somecommand ...

...which puts the assignment into the subshell running the first component of the pipeline (if your shell is indeed running that component in a subshell, which is undefined behavior inasmuch as POSIX is concerned; from the spec: "as an extension, however, any or all commands in a pipeline may be executed in the current environment").

The reason is that this sets an environment variable for one line. But, echo does not do the expansion, bash does. Hence, your variable is actually expanded before the command is executed, even though SOME_VAR is BBB in the context of the echo command.

To see the effect, you can do something like:

$ SOME_VAR=BBB bash -c 'echo $SOME_VAR'
BBB

Here the variable is not expanded until the child process executes, so you see the updated value. if you check SOME_VARIABLE again in the parent shell, it's still AAA, as expected.

Put simply, the $SOMEVAR is evaluated before the command is called while prepending SOMEVAR=BBB in front of the command modifies the environment of the command you're running.

As Charles Duffy said, you can add an intermediate sh process that will evaluate the variable with a similar syntax but you probably want to do something a bit more elaborate and it'd be useful to know what if you still have troubles with it.

SOMEVAR=BBB; echo zzz $SOMEVAR zzz

Use a ; to separate statements that are on the same line.

SOMEVAR=BBB echo zzz $SOMEVAR zzz

will add SOMEVAR=BBB into the environment variables and then execute echo zzz $SOMEVAR zzz. The $SOMEVAR refers to the shell variable SOMEVAR which you have set to AAA beforehand.

Adding the semi colon SOMEVAR=BBB; echo zzz $SOMEVAR zzz sets the shell variable to BBB and then executes the command after the semi-colon, i.e echo zzz $SOMEVAR zzz and produces zzz BBB zzz.

Try this command:

SOMEVAR=BBB env | less

and look at the environment.

Here's one alternative:

SOMEVAR=BBB && echo zzz $SOMEVAR zzz