helpThe GNU Bourne-Again SHell - Support: sr #109649, ${!var} fails on 4.4 with bad...


sr #109649: ${!var} fails on 4.4 with bad substitution error

Submitter:  None
Submitted:  Fri 01 Mar 2019 10:51:16 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)

Comment Type & Canned Response:


( Jump to the original submission )

Wed 06 Mar 2019 01:13:43 AM UTC, comment #7: 

Alrighty then.  Thanks again for taking a look and discussion.  If you're curious, the Hadoop JIRA to fix the issue on our side is

Tue 05 Mar 2019 07:12:35 PM UTC, comment #6: 

I wouldn't assume that "the new behavior doesn't fix a bug that was blocking users." The original bug report that prompted the fix was a crash based on an attempt to indirectly reference an invalid variable name (in that case, ${!-3}). Consistency argues for treating all invalid variable names the same, even if the effects of using them vary in severity.

I don't see any particular value in letting clearly invalid names through silently, since they most often aren't intended (in the reported case, it was a typo), and there's the inevitable issue with carving out exceptions.

I'd rather have consistent, correct behavior.

Chet Ramey <chet>
Project Administrator
Tue 05 Mar 2019 05:54:30 PM UTC, comment #5: 

Not exactly.  In a scenario where behavior is broken, fixing the bug is OK because the number of users negatively impacted by the bug typically outweighs the number of users impacted by the fix.  That's not this case, though.

In this case the new behavior doesn't fix a bug that was blocking users.  There were no applications that were depending on bash printing an error when doing a substitution for a var with a dot.  (That's an assumption, so if I'm wrong, I yield.)  There were, however, applications depending on bash not doing that.

These are the challenges of API development.  Google around, and you'll find lots of cases where a "broken" API had to be left alone because users had come to depend on the behavior.

But, as I said before, we'll work around the regression either way.  This discussion is at this point academic.

Tue 05 Mar 2019 05:43:01 PM UTC, comment #4: 

By that logic, you can never fix a bug because someone might depend on the buggy behavior.

Chet Ramey <chet>
Project Administrator
Tue 05 Mar 2019 05:33:33 PM UTC, comment #3: 

Chet, I agree in the abstract.  Dots aren't allowed in var names, so it's better to complain up front if someone tries to substitute one.

However, 4.3 did not complain, which makes the change in 4.4 a regression.  Scripts that used to work are now broken.  It's clearly your call whether the bash project cares.  We'll work around the issue in Hadoop with a patch to change the way the scripts work, but others may encounter the same issue.

Thanks for taking a look.

Tue 05 Mar 2019 03:55:11 PM UTC, comment #2: 

A variable name can't contain a dot. It was a bug in bash-4.3 that it allowed this. There's no reason that a variable the shell wouldn't accept on its own should be allowed as the target of variable indirection.

Chet Ramey <chet>
Project Administrator
Sun 03 Mar 2019 11:03:48 PM UTC, comment #1: 

After a little more digging the issue is that in 4.4 on Ubuntu 18, the name of the substituted variable cannot contain a dot.  Here's a more illuminating example:

% docker run -ti ubuntu:18.04 /bin/bash
root@36ce0eb1d846:/# j="hi"
root@36ce0eb1d846:/# m="bye"
root@36ce0eb1d846:/# k=j
root@36ce0eb1d846:/# echo ${!k}
root@36ce0eb1d846:/# k=m
root@36ce0eb1d846:/# echo ${!k}
root@36ce0eb1d846:/# k=l
root@36ce0eb1d846:/# echo ${!k}

root@36ce0eb1d846:/# k=l.m
root@36ce0eb1d846:/# echo ${!k}
bash: l.m: bad substitution

On bash 4.3 on Ubuntu 16, that last command prints the same thing as the previous one.

Fri 01 Mar 2019 10:51:16 PM UTC, original submission:  

On Ubuntu 16 with bash 4.3, this works:

% docker run -ti ubuntu:16.04 /bin/bash
root@6c922538b590:/# bash --version
GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
root@6c922538b590:/# echo $uvar
root@6c922538b590:/# echo ${!uvar}

root@6c922538b590:/# exit

On Ubuntu 18 with bash 4.4, it doesn't:

% docker run -ti ubuntu:18.04 /bin/bash
root@945210786cd4:/# bash --version
GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
root@945210786cd4:/# echo $uvar
root@945210786cd4:/# echo ${!uvar}



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

Attach Files:

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 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
    2019-03-05 chet StatusNone Invalid

    Back to the top

    Powered by Savane 3.10