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
