Re: param expansion with single-character special vars in the environment

[Dan Douglas]

...Also remember it isn't feasible to actually validate a "name" in a
script because a name can contain a subscript with a command
substitution that effectively requires parsing the full language.
(there are some tricks like with `set -nv` and reading its output to
shanghai the shell parser into doing your bidding, but that's not very
practical.). Before bash had namerefs, it could ignore aspects of
"invalid" names, like trailing characters after an array subscript,
which makes some valid ksh names at least get partially interpreted in
bash, like `a[foo].bar` or `a[foo][bar]`.

Re: param expansion with single-character special vars in the environment

[Dan Douglas]

On Wed, May 4, 2016 at 2:37 PM, Piotr Grzybowski  wrote:
>
> On 4 May 2016, at 17:51, Chet Ramey wrote:
>
>> The issue I'm thinking about currently is whether or not to allow nameref
>> variables to have numeric (integer) values.  bash-4.3 didn't allow those
>> values to be expanded, but allowed them to be assigned.  It doesn't seem
>> harmful to change the error to assignment time.
>
> I vote for error at assignment, whats the point of allowing pointless 
> assignment?

Since almost all bash errors are runtime errors that you might never
hit until something you didn't expect gets passed the wrong value,
errors (especially fatal errors) that might sound like a good idea at
first end up being totally pathological. You end up having to manually
test and validate all inputs to all functions whose callers aren't
strictly controlled, or add redirects to hide warning messages for
non-fatal errors. There are even cases where it's useful to allow or
at least ignore invalid names. If this were a language where I could
get a compiler error caught through static analysis then it would be a
different story.

Re: namref dicussion continued: [PATCH] export -r reference

[Dan Douglas]

Yeah I was just looking for this old script last night and just found it :)

https://gist.github.com/ormaaj/04923e11e8bdc27688ad

If you scroll down to the output for "test 3" where "h" gets called
and passes a local "x" to a function that creates a reference to it
and exports the reference you can see that bash calls "x" unset in
both the first and second scope. As I recall we were discussing the
way exported locals interact between scopes at the time, not namerefs,
but I added the case for namerefs since I wasn't sure how this should
work. I should probably run it again with the current devel branch.

Even though bash doesn't yet support references for parameters like
ksh93, neither does mksh, which also shows differences from bash.

Re: param expansion with single-character special vars in the environment

[Piotr Grzybowski]

On 4 May 2016, at 17:51, Chet Ramey wrote:

> The issue I'm thinking about currently is whether or not to allow nameref
> variables to have numeric (integer) values.  bash-4.3 didn't allow those
> values to be expanded, but allowed them to be assigned.  It doesn't seem
> harmful to change the error to assignment time.

I vote for error at assignment, whats the point of allowing pointless 
assignment?

pg

namref dicussion continued: [PATCH] export -r reference

[Piotr Grzybowski]

Hey,

 after another discussion with Grisha, and following one of his remarks, I 
kindly request your opinion on the attached patch (like: bad, not needed, 
already done, weak as it stands, harmful, etc.). It addresses the exporting of 
identifiers with have nameref attribute set.
 at the moment we have:

#a=10; declare -nx ra=a; bash -c 'echo "a:$a, ra:$ra, ra_excl:${!ra}."' 
a:, ra:a, ra_excl:.
#a=10; declare -n ra=a; export ra; bash -c 'echo "a:$a, ra:$ra, 
ra_excl:${!ra}."'
a:10, ra:a, ra_excl:10

so either you get reference value exported (not very useful, and probably not 
the intent when typing declare -nx reference=variable;), or you get the 
referenced variable exported, which is not necessarily expected, together with 
the variable with the reference value.

The patch makes both of them work the same, and resolving the reference at 
export:

bash-4.4$ a=10; declare -nx ra=a; bash -c 'echo "a:$a, ra:$ra, 
ra_excl:${!ra}."' 
a:, ra:10, ra_excl:.
bash-4.4$ a=10; declare -n ra=a; export ra; bash -c 'echo "a:$a, ra:$ra, 
ra_excl:${!ra}."'
a:, ra:10, ra_excl:.

and also introduces a way to recover the current behaviour with the exporting 
of the target variable:

bash-4.4$ a=10; declare -n ra=a; export -r ra; bash -c 'echo "a:$a, ra:$ra, 
ra_excl:${!ra}."'
a:10, ra:10, ra_excl:.

there are of course other possibilities to consider, but I agree with Grisha, 
that it is worthy of at least taking a look.

cheers,
pg






follow_references_on_export.patch
Description: Binary data