mainThe GNU Bourne-Again SHell - Support: sr #110662, Reading multiple variables from...

 
 

sr #110662: Reading multiple variables from here string broken in bash 5.x

Submitter:  None
Submitted:  Mon 23 May 2022 09:23:01 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Invalid
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 27 May 2022 05:15:12 PM UTC, comment #3: 

On the contrary, the bash behavior is exactly what you should
expect.

If you go through the steps, it should become obvious why you get
the results you do.

The here-string contents are

1
2
3

which are presented to the read builtin on its standard input.

The read builtin reads one line, or until it encounters the
delimiter, which in this case is the same thing.

That line is `1'.

read then attempts to assign the contents of the line, after it
performs a form of word splitting, to the variables supplied as
arguments. So `a' gets `1', and that consumes the line.

Since there are more variables than fields in the line, the
remaining variables get assigned the empty string. That means
`b' and `c' are ''.

Chet Ramey <chet>
Group administrator
Fri 27 May 2022 03:33:17 PM UTC, comment #2: 

So just to be clear, if I correct the -d argument to $'\n' it should work as expected?  It does not seem to:

$ read -d$'\n' a b c <<< "$(echo -e "1\n2\n3")" ; echo "$b"

$

Anonymous
Wed 25 May 2022 10:26:15 PM UTC, comment #1: 

This was broken until bash-4.4-beta.

Versions before that word-split the word in a here-string,
despite the documentation saying that it did not. The effect of
this was to change IFS characters in the expanded string to
spaces, so the contents of the here-string would be

1 2 3

in bash-4.2. Look at

https://lists.gnu.org/archive/html/bug-bash/2015-09/msg00022.html

for the report.

When I changed the behavior to match the documentation, and
removed the word splitting, the contents of the here-string
became

1
2
3

You can see why b is assigned the empty string.

Your final example doesn't tell `read' to use newline as a
delimiter; it tells it to use `\'. If you want to use newline,
you need to specify it as -d$'\n'. `read' doesn't perform that
kind of translation on the argument to `-d' itself.

Chet Ramey <chet>
Group administrator
Mon 23 May 2022 09:23:01 PM UTC, original submission:  

This works fine in bash 4.2:

$ read a b c <<< $(echo -e "1\n2\n3") ; echo $b
2
$

But in bash 5.1:

$ read a b c <<< $(echo -e "1\n2\n3") ; echo $b

$

Oddly, if we tell read to use newline as a delimiter (even though the docs claim that is the default) it works in 5.1:

$ read -d'\n' a b c <<< $(echo -e "1\n2\n3") ; echo $b
2
$


Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by None (Posted a comment)
  • -email is unavailable- added by chet (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-05-25 chet StatusNone Invalid

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code