10

I need to read some configuration data into environment variables in a bash script.

The "obvious" (but incorrect) pattern is:

egrep "pattern" config-file.cfg | read VAR1 VAR2 VAR3 etc...

This fails because the read is run in a subshell and therefore cannot set variables in the invoking shell. So I came up with this as an alternative

coproc egrep "pattern" config-file.cfg
read -u ${COPROC[0]} VAR1 VAR2 VAR3 etc...

which works fine.

To test what happens if the coprocess returns more than one line, I tried this:

coproc cat config-file.cfg
read -u ${COPROC[0]} VAR1 VAR2 VAR3 etc...

where config-file.cfg contains three lines.

$ cat config-file.cfg
LINE1 A1 B1 C1
LINE2 A2 B2 C2
LINE3 A3 B3 C3

I expected this to process the first line in the file, followed by some kind of "broken pipe" error message. While it did process the first line, there was no error message and no coprocess was left running.

So I then tried the following in a script:

$ cat test.sh
coproc cat config-file.cfg
read -u ${COPROC[0]} VAR1 VAR2 VAR3 VAR4
echo $VAR1 $VAR2 $VAR3 $VAR4
wait
echo $?

Running it:

$ bash -x test.sh
+ read -u 63 VAR1 VAR2 VAR3 VAR4
+ cat config-file.cfg
LINE1 A1 B1 C1
+ wait
+ echo 0
0

Where did the remaining two lines go? I would have expected either "broken pipe", or the wait to hang since there was nothing to read the remaining lines, but as you can see the return code was zero.

Jim Garrison
  • 85,615
  • 20
  • 155
  • 190
  • 4
    Unless I'm missing something, something like `read VAR1 VAR2 VAR3 < <(egrep "pattern" config-file.cfg)` would suffice, no? – Shawn Chin Oct 04 '11 at 17:54
  • 2
    @ShawnChin: that's ignoring the question. Coprocs are cool foor good reasons that the OP doesn't have to explain first – sehe Oct 04 '11 at 18:04
  • 1
    Do pardon my ignorance. I admit coprocs are cool, but the comment was a response to a passing thought that coprocs might be an overkill if it's simply to avoid `read running in a subshell and loosing the vars. I'm probably mistaken, as usual. – Shawn Chin Oct 04 '11 at 18:32
  • @ShawnChin: Your guess was correct, that's what I'm looking for. I was unaware of the syntax in your first comment: `< <(egrep "pattern" config-file.cfg)`. The bash reference calls this "process substitution" and the description is wonderfully misleading: _"If the <(list) form is used, the file passed as an argument should be read to obtain the output of list"_ -- what "file passed as an agrument" are they talking about? – Jim Garrison Oct 04 '11 at 19:05
  • @ShawnChin: Make your comment an answer; it's what I needed. – Jim Garrison Oct 04 '11 at 19:06

3 Answers3

6

As per comments above, you can use process substitution to achieve just that. This way, read is not run in a subshell and the captured vars will be available within the current shell.

read VAR1 VAR2 VAR3 < <(egrep "pattern" config-file.cfg)

"If the <(list) form is used, the file passed as an argument should be read to obtain the output of list" -- what "file passed as an agrument" are they talking about?

That is rather cryptic to me too. The chapter on process substitution in Advanced Bash-scripting Guide has a more comprehensive explanation.

The way I see it, when the <(cmd) syntax is used, the ouput of cmd is made available via a named pipe (or temp file) and the syntax is replaced by the filename of the pipe/file. So for the example above, it would end up being equivalent to:

read VAR1 VAR2 VAR3 < /dev/fd/63

where /dev/fd/63 is the named pipe connected to the stdout of cmd.

Shawn Chin
  • 84,080
  • 19
  • 162
  • 191
2

If I understand correctly your question (and I hope I'm not stating the obvious), read reads one line at a time, as in:

$ read a b c < config-file.cfg && echo $?
0

or:

$ printf '%s\n%s\n' one two | { read; echo "$REPLY";}
one

$ echo ${PIPESTATUS[@]}
0 0

To read all the input you'll need a loop:

$ coproc cat config-file.cfg
[1] 3460

$ while read -u ${COPROC[0]} VAR1 VAR2 VAR3; do echo $VAR1 $VAR2 $VAR3; done
LINE1 A1 B1 C1
LINE2 A2 B2 C2
LINE3 A3 B3 C3
[1]+  Done                    coproc COPROC cat config-file.cfg

Just to add that this is explained in the FAQ.

Dimitre Radoulov
  • 27,252
  • 4
  • 40
  • 48
  • 1
    No, I understand that `read` reads one line at a time. What I was wondering was what happened to the buffered lines when you read only one of them. I was expecting an error or hang, but they just disappeared, which is actually what I want, but I hate "magic" I don't understand and can't predict. – Jim Garrison Oct 04 '11 at 19:02
  • The co-proc just doesn't wait for you to read it's input (just like a regular pipe), it times out. Consider the following: `$ { echo 1; echo 2;} 1 2` and `$ { echo 1; echo 2;} | { read; echo $REPLY; } 1`. Where 2 went? – Dimitre Radoulov Oct 04 '11 at 20:13
  • So, to reformulate the answer: in this case the co-process exits when it sees an end-of-file on its input. Bart Shaefer wrote a very nice tutorial on co-processes, you can find it [here](http://www.zsh.org/mla/users/2011/msg00095.html). – Dimitre Radoulov Oct 04 '11 at 20:48
1

What happens is, as soon as the subshell finishes, the parent shell cleans up and closes the FDs. You're lucky you even got to read the first line!

Try this in an interactive shell:

$ coproc ECHO { echo foo; echo bar; }
[2] 16472
[2]+  Done                    coproc ECHO { echo foo; echo bar; }
$ read -u ${ECHO[0]}; echo $REPLY
bash: read: -u: option requires an argument
read: usage: read [-ers] [-a array] [-d delim] [-i text] [-n nchars] [-N nchars] [-p prompt] [-t timeout] [-u fd] [name ...]

It even mops up the environment variable.

Now try this:

$ coproc ECHO { echo foo; echo bar; sleep 30; }
[2] 16485
$ read -u ${ECHO[0]}; echo $REPLY
foo
$ read -u ${ECHO[0]}; echo $REPLY
bar
$ read -u ${ECHO[0]}; echo $REPLY # blocks until the 30 seconds are up

[2]+  Done                    coproc ECHO { echo foo; echo bar; sleep 30; }

As for solving the problem behind the question: Yes, redirection and process substitution is the better choice for the particular example given.

clacke
  • 7,688
  • 6
  • 46
  • 48