CODEWITHSUNDEEP
bashenvironment-variablesechofifo
nickackerman42
nickackerman42

Reputation: 515

Echo-ing an environment variable returns string literal rather than environment variable value

I have two bash scripts. The first listens to a pipe "myfifo" for input and executes the input as a command:

fifo_name="myfifo"

[ -p $fifo_name ] || mkfifo $fifo_name;

while true
do
  if read line; then
    $line
  fi
done <"$fifo_name"

The second passes a command 'echo $SET_VAR' to the "myfifo" pipe:

command='echo $SET_VAR'
command_to_pass="echo $command"
$command_to_pass > myfifo

As you can see, I want to pass 'echo $SET_VAR' through the pipe. In the listener process, I've set a $SET_VAR environment variable. I expect the output of the command 'echo $SET_VAR' to be 'var_value,' which is the value of the environment variable SET_VAR.

Running the first (the listener) script in one bash process and then passing a command via the second in another process gives the following result:

$SET_VAR

I expected to "var_value" to be printed. Instead, the string literal $SET_VAR is printed. Why is this the case?

Upvotes: 0

Views: 1951

Answers (2)

hek2mgl
hek2mgl

Reputation: 157947

bash, by it's nature, reads commands from stdin. You can simply run:

bash < myfifo

Upvotes: 1

Gordon Davisson
Gordon Davisson

Reputation: 125728

Before I get to the problem you're reporting, I have to point out that your loop won't work. The while true part (without a break somewhere in the loop) will run forever. It'll read the first line from the file, loop, try to read a second line (which fails), loop again, try to read a third line (also fails), loop again, try to read a fourth line, etc... You want the loop to exit as soon as the read command fails, so use this:

while read line
do
    # something I'll get to
done <"$fifo_name"

The other problem you're having is that the shell expands variables (i.e. replaces $var with the value of the variable var) partway through the process of parsing a command line, and when it's done that it doesn't go back and re-do the earlier parsing steps. In particular, if the variable's value included something like $SET_VAR it doesn't go back and expand that, since it's just finished the bit where it expands variables. In fact, the only thing it does with the expanded value is split it into "words" (based on whitespace), and expand any filename wildcards it finds -- no variable expansions happen, no quote or escape interpretation, etc.

One possible solution is to tell the shell to run the parsing process twice, with the eval command:

while read line
do
    eval "$line"
done <"$fifo_name"

(Note that I used double-quotes around "$line" -- this prevents the word splitting and wildcard expansion I mentioned from happening before eval goes through the normal parsing process. If you think of your original code half-parsing the command in $line, without double-quotes it gets one and a half-parsed, which is weird. Double-quotes suppress that half-parsing stage, so the contents of the variable get parsed exactly once.)

However, this solution comes with a big warning, because eval has a well-deserved reputation as a bug magnet. eval makes it easy to do complex things without quite understanding what's going on, which means you tend to get scripts that work great in testing, then fail incomprehensibly later. And in my experience, when eval looks like the best solution, it probably means you're trying to solve the wrong problem.

So, what're you actually trying to do? If you're just trying to execute the lines coming from the fifo as shell commands, then you can use bash "$fifo_name" to run them in a subshell, or source "$fifo_name" to run them in the current shell.

BTW, the script that feeds the fifo:

command='echo $SET_VAR'
command_to_pass="echo $command"
$command_to_pass > myfifo

Is also a disaster waiting to happen. Putting commands in variables doesn't work very well in the shell (I second chepner's recommendation of BashFAQ #50: I'm trying to put a command in a variable, but the complex cases always fail!), and putting a command to print another command in a variable is just begging for trouble.

Upvotes: 3

Related Questions