On Fri, May 20, 2016 at 3:05 PM, Chet Ramey <chet.ra...@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
