33

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?

ilkkachu
  • 138,973
Emmanuel
  • 4,187

2 Answers2

46

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.

Michael Homer
  • 76,565
  • 3
    Or even read a b dump <<< '1 2 3 4 5'. – choroba Jul 11 '14 at 10:41
  • Thank you to all, btw I noted that mksh (on cygwin) is doing the same as bash. – Emmanuel Jul 11 '14 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. – Yurij Goncharuk May 03 '18 at 10:28
25

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
jlliagre
  • 61,204
  • 1
    +1 thank you for the "lastpipe" info. sorry for the delay – Emmanuel Jul 29 '14 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 http://stackoverflow.com/questions/36268479/avoid-subshell-from-pipe-on-dash – anarcat Feb 08 '17 at 15:46
  • 2
    @anarcat This is correct but the question asked here was about bash. – jlliagre Feb 08 '17 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: https://unix.stackexchange.com/questions/476834/read-from-stdin-works-differently-in-bash-and-zsh/476837#476837 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 Oct 21 '18 at 13:42