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

Submitted by:  None
Submitted on:  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

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( 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 https://issues.apache.org/jira/browse/HADOOP-16167.

Anonymous
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.

Anonymous
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.

Anonymous
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:

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

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

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

Anonymous
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 <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@6c922538b590:/# uvar=HADOOP_ORG.APACHE.HADOOP.CONF.CONFIGURATION_USER
root@6c922538b590:/# echo $uvar
HADOOP_ORG.APACHE.HADOOP.CONF.CONFIGURATION_USER
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 <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@945210786cd4:/# uvar=HADOOP_ORG.APACHE.HADOOP.CONF.CONFIGURATION_USER
root@945210786cd4:/# echo $uvar
HADOOP_ORG.APACHE.HADOOP.CONF.CONFIGURATION_USER
root@945210786cd4:/# echo ${!uvar}
bash: HADOOP_ORG.APACHE.HADOOP.CONF.CONFIGURATION_USER: bad substitution

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 chet (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    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.5