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?


2 Answers 2


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.

  • 3
    Or even read a b dump <<< '1 2 3 4 5'.
    – choroba
    Commented Jul 11, 2014 at 10:41
  • Thank you to all, btw I noted that mksh (on cygwin) is doing the same as bash.
    – Emmanuel
    Commented Jul 11, 2014 at 10:56
  • @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. Commented May 3, 2018 at 10:28

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


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:


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 


after: 2 1
  • 1
    +1 thank you for the "lastpipe" info. sorry for the delay
    – Emmanuel
    Commented Jul 29, 2014 at 14:47
  • 1
    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/…
    – anarcat
    Commented Feb 8, 2017 at 15:46
  • 2
    @anarcat This is correct but the question asked here was about bash.
    – jlliagre
    Commented Feb 8, 2017 at 15:49
  • @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.
    – schily
    Commented Oct 21, 2018 at 13:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .