Re: nameref in temp environment

[Grisha Levit]

On Fri, May 20, 2016 at 3:05 PM, Chet Ramey <chet.ramey@case.edu> 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 like var=foo printenv var should always print foo, no matter what attributes (other than readonly) are assigned to $var. This is based on the existing behavior, where stuff like subscript assignments, compound assignments, var’s -i/-u/-l flags, are all ignored in this context.

I think the issue of += is hard to handle consistently without considering the changes to export behavior Piotr and I were discussing earlier. Consider the cases below — I think it would be least surprising if they produced the same result.

declare -nx ref=var; var=foo; str=''
printenv ref                 # var
ref+=$str    printenv ref    # empty string...
ref+="$str"  printenv ref    # foo
ref=$ref$str printenv ref    # foo

If += were changed to use the name of the target variable, the last two cases would differ, which seems most strange.

BTW, perhaps exported (resolved) namerfs seem like a silly use case, but I think the idea could actually be really useful for legitimate shell stuff, like:

declare -nx DYLD_LIBRARY_PATH=LD_LIBRARY_PATH    # add Darwin compat
# existing *nix code here

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)

• the target variable is added to the export list if it was not there before (for ksh93 compat)

• if $ref is a nameref but is not valid for assignment (or is not set)

  • ref=x puts ref=x in the env
  • ref+=x puts ref=${ref}x in the env (using the target’s value)
• the nameref variable is added to the export list with the new value of its target

​