Re: indirect variable behavior breakage

[christopher barry]

On Wed, 7 Mar 2018 09:51:59 -0500
Chet Ramey <chet.ramey@case.edu> wrote:

> On 3/6/18 11:38 PM, christopher barry wrote:
> 
> > Bash Version: 4.4 (does not work)
> > Patch Level: 12
> > Release Status: release
> > 
> > 
> > Description:
> > 
> > a simple function that is used to test if a var is indirect or not
> > and return the value whether indirect or simply a string is no
> > longer working as expected on newer versions of bash.
> > 
> > Repeat-By:
> > 
> > This function works fine on this version (4.3.43) of bash (and
> > all previous versions I have access to, e.g. 4.2.46). It is broken,
> > that I am aware of, in 4.4.12 and 4.4.19, and possibly other
> > versions as well.
> > 
> >  function ivar() { echo -n "${!1:-${1}}"; }
> > 
> > This will take in a word as $1, and if it is a ref, will echo the
> > value of ref, but if it is not, will simply echo $1. This function
> > cares not about the string handed in, it rejects the indirection
> > silently, and IMHO correctly, regardless of the characters in that
> > string. I have found this function to be incredibly handy, and it's
> > in extensive use. It's simplicity and usefulness are very much
> > relied upon.
> > 
> > Now, if the string starts with a number, or has a dash (possibly
> > other chars as well), it throws a syntax error. It's not clear to
> > me why it now feels the need to do this.  
> 
> The strings you're describing are invalid variable names. They would
> generate variable expansion errors if used directly; why should they
> not generate the same error when used as the value of an indirect
> expansion? The two cases are supposed to be identical.
> 
> These should all generate errors (and in bash-4.4, they generate
> the same `bad substitution' error):
> 
> echo "${-3:-${-3}}";
> echo ${-3}
> 
> x=-3
> echo ${!x}
> 
> function ivar() { echo -n "${!1:-${1}}"; }
> ivar -3
> 
> It was a bug in bash-4.3 that the latter two cases didn't produce
> errors, and, in the `!x' case, produced random output and occasional
> core dumps.
> 
> Chet


Hi Chet,

Thanks the quick reply, for bash and all the work you've put into it,
and thanks for continuing to fix bugs too.

Of course sanitizing the input before evaluation is always good, and
your fix does just that by seeing an invalid var name and throwing an
error. Finding it's invalid is good, throwing an error is possibly
overkill.

My point is, I already cannot:

$ declare -3=myval
bash: declare: -3: invalid option
declare: usage: declare [-aAfFgilrtux] [-p] [name[=value] ...]

$ declare wrong-name=100
bash: declare: `wrong-name=100': not a valid identifier

$ declare 3var=something
bash: declare: `3var=something': not a valid identifier

and I cannot create any other variable that has an invalid name because
bash correctly disallows it from ever occurring.


So yes 'ivar -3' is very, very bad indeed, and was a nasty bug, and I
absolutely agree that making sure the string is a validly formatted var
name before attempting to evaluate it is the right approach.

My only request is for bash to not throw an error when it realizes
it's invalid. Returning 1 and no data seems like a reasonable response
that fixes the prior bug, but will not break this use-case.

Is there a reason this is an unreasonable request or an undesirable
behavior I am not understanding?


Thanks again,

Christopher Barry
Rajant