In bash, read after a pipe is not setting values

Question

With ksh I'm using read as a convenient way to separate values:

$ echo 1 2 3 4 5 | read a b dump
$ echo $b $a 
2 1
$

But it fails in Bash:

$ echo 1 2 3 4 5 | read a b dump
$ echo $b $a 
 
$

I didn't find a reason in the man page why it fails, any idea?

• Scott - Слава Україні: This is discussed (somewhat obscurely) in page 024 of Greg’s Bash FAQ.
• ilkkachu: Also similar: Why is my variable local in one 'while read' loop, but not in another seemingly similar loop?

Answer 1

bash runs the right-hand side of a pipeline in a subshell context, so changes to variables (which is what read does) are not preserved — they die when the subshell does, at the end of the command.

Instead, you can use process substitution:

$ read a b dump < <(echo 1 2 3 4 5)
$ echo $b $a
2 1

In this case, read is running within our primary shell, and our output-producing command runs in the subshell. The <(...) syntax creates a subshell and connects its output to a pipe, which we redirect into the input of read with the ordinary < operation. Because read ran in our main shell the variables are set correctly.

As pointed out in a comment, if your goal is literally to split a string into variables somehow, you can use a here string:

read a b dump <<<"1 2 3 4 5"

I assume there's more to it than that, but this is a better option if there isn't.

• choroba: Or even read a b dump <<< '1 2 3 4 5'.
• Emmanuel: Thank you to all, btw I noted that mksh (on cygwin) is doing the same as bash.
• Yurij Goncharuk: @Michael Homer Good explanation! I found another one example that can explain that every command in pipeline run in own subshell: cat /etc/passwd | (read -r line ; echo $line). But next echo of $line which is not in pipeline put nothing on screen, because value was existed just between parentheses (subshell) . Hope, It helps someone.

Answer 2

This is not a bash bug as POSIX allows both bash and ksh behaviors, leading to the unfortunate discrepancy you are observing.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_12

Additionally, each command of a multi-command pipeline is in a subshell environment; as an extension, however, any or all commands in a pipeline may be executed in the current environment. All other commands shall be executed in the current shell environment.

However, with bash 4.2 and newer, you can set the lastpipe option in non interactive scripts to get the expected result, eg:

#!/bin/bash
echo 1 2 3 4 5 | read a b dump
echo before: $b $a 
shopt -s lastpipe
echo 1 2 3 4 5 | read a b dump
echo after: $b $a 

Output:

before:
after: 2 1

• Emmanuel: +1 thank you for the "lastpipe" info. sorry for the delay
• anarcat: the problem with lastpipe is that it doesn't work in other shells (e.g. dash). there's basically no way to do this portable short of running everything in that subshell, see stackoverflow.com/questions/36268479/…
• jlliagre: @anarcat This is correct but the question asked here was about bash.
• schily: @anarcat: This may change in the future since there is a wish to change POSIX for another reason (PIPE Status) see here: unix.stackexchange.com/questions/476834/… Changing other shells is not trivial, it took me several months to rewrite the parser and interpeter on the Bourne Shell (bosh) to implement the faster behavior of the modern ksh.