Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1514300 - [here string] uncompatible change on here string function; is it new feature or a bug?
Summary: [here string] uncompatible change on here string function; is it new feature ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: 27
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Siteshwar Vashisht
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-17 02:34 UTC by Yin.JianHong
Modified: 2018-01-04 12:49 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-22 09:57:38 UTC


Attachments (Terms of Use)

Description Yin.JianHong 2017-11-17 02:34:13 UTC
Description of problem:

bash 4.4 '''
[yjh@bash4.4 ~]$ LANG=C bash --version|head -n1
GNU bash, version 4.4.12(1)-release (x86_64-redhat-linux-gnu)
[yjh@bash4.4 ~]$ echo $(echo -e "foo\nbar")
foo bar
[yjh@bash4.4 ~]$ read a b <<<$(echo -e "foo\nbar"); echo $a:$b
foo:
    # ^^^ here $b is empty
[yjh@bash4.4 ~]$ read a <<<$(echo -e "foo\t\tbar")
[yjh@bash4.4 ~]$ echo "$a"
foo		bar
'''

bash 4.2 '''
[yjh@bash4.2 ~]$ bash --version
GNU bash, version 4.2.46(1)-release (x86_64-redhat-linux-gnu)
[yjh@bash4.2 ~]$ echo $(echo -e "foo\nbar")
foo bar
[yjh@bash4.2 ~]$ read a b <<<$(echo -e "foo\nbar"); echo $a:$b
foo:bar
[yjh@bash4.2 ~]$ read a <<<$(echo -e "foo\t\tbar")
[yjh@bash4.2 ~]$ echo "$a"
foo bar
'''

Version-Release number of selected component (if applicable):
bash 4.4

How reproducible:
100%


Steps to Reproduce:
1. read a b <<<$(echo -e "foo\nbar")
2. check if $b is "bar"

Actual results:
[yjh@bash4.4 ~]$ read a <<<$(echo -e "foo\t\tbar")
[yjh@bash4.4 ~]$ echo "$a"
foo		bar

Expected results:
[yjh@bash4.2 ~]$ read a <<<$(echo -e "foo\t\tbar")
[yjh@bash4.2 ~]$ echo "$a"
foo bar


Additional info:

Comment 1 Kamil Dudka 2017-11-20 10:42:43 UTC
Single invocation of 'read' should read a single line from standard input.  It
was a bug in bash-4.2 that it converted 0x0a (new line) to 0x20 (space) in the
here strings syntax:

$ hexdump -C <<< $(printf "foo\nbar")
00000000  66 6f 6f 20 62 61 72 0a                           |foo bar.|

Comment 2 Yin.JianHong 2017-11-21 00:47:54 UTC
(In reply to Kamil Dudka from comment #1)
> Single invocation of 'read' should read a single line from standard input. 
> It
> was a bug in bash-4.2 that it converted 0x0a (new line) to 0x20 (space) in
> the
> here strings syntax:
> 
> $ hexdump -C <<< $(printf "foo\nbar")
> 00000000  66 6f 6f 20 62 61 72 0a                           |foo bar.|

do you know the difference between 
 echo "$(printf "foo\nbar")"
and
 echo $(printf "foo\nbar")

 echo $(ls)
and
 echo "$(ls)"

Comment 3 Yin.JianHong 2017-11-21 03:12:21 UTC
JFYI:
 bash-3.2.25(RHEL-5 U11) bash-4.1.2(RHEL-6) are same as bash-4.2(RHEL-7)

'''
[root@sgi-xe250-02 ~]# bash --version
GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
[root@sgi-xe250-02 ~]# read a <<<$(echo -e "foo\t\tbar"); echo "$a"
foo bar
'''

'''
[root@hp-dl380pg8-14 ~]# bash --version
GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
[root@hp-dl380pg8-14 ~]# read a <<<$(echo -e "foo\t\tbar"); echo "$a"
foo bar
'''

Comment 4 Siteshwar Vashisht 2017-11-21 13:59:11 UTC
As kdudka mentioned, this is not a bug in bash.

Comment 5 Yin.JianHong 2017-11-22 01:56:37 UTC
Obviously it is a bug

Comment 6 Kamil Dudka 2017-11-22 09:57:38 UTC
It was a bug in bash-4.2 (and bash-4.3).  The change of behavior in bash-4.4
you are observing is actually a fix of the bug.  See comment #1.  Moreover,
the current behavior matches the behavior of ksh and zsh.  As the fix of bash
is included in all supported Fedora releases, it makes no sense to reopen
this (not a) bug.


Note You need to log in before you can comment on or make changes to this bug.