On 5/20/16 6:47 PM, Grisha Levit wrote:
> I would propose that the following behavior would be least surprising for
> assignments before command names:
>
> * iff |$ref| is a valid nameref for assignment, assigning/appending to
> |ref| modifies the target variable (for ksh93 compat)
> *
>
On Fri, May 20, 2016 at 3:05 PM, Chet Ramey wrote:
It uses the existing variable for the readonly check and the
> existing value to perform an append if desired. I can see using the
> nameref itself for both of those; what do you think?
I was thinking that desirable behavior is that something l
On 5/12/16 8:58 PM, Grisha Levit wrote:
> The 20160506 snapshot changes assign_in_env to do some nameref-related
> checks on the variable name, but these don’t really seem to make sense
> since assignments in the temporary env just create regular variables and
> don’t follow the nameref chain other
On 5/12/16 8:58 PM, Grisha Levit wrote:
> The 20160506 snapshot changes assign_in_env to do some nameref-related
> checks on the variable name, but these don’t really seem to make sense
> since assignments in the temporary env just create regular variables and
> don’t follow the nameref chain other
hi,
there are two issues here, small regressions.
I think in tmpenv we should create the variable unconditionally (concerning
the namerefs), and should not follow the namerefs on checking if the variable
exists:
diff --git a/variables.c b/variables.c
index 1877b17..f149b66 100644
--- a/variab
The 20160506 snapshot changes assign_in_env to do some nameref-related
checks on the variable name, but these don’t really seem to make sense
since assignments in the temporary env just create regular variables and
don’t follow the nameref chain otherwise.
i.e. bash doesn’t actually care that ref
