[BUG] Tied parameters not restored correctly after pre-command re-assignment

[BUG] Tied parameters not restored correctly after pre-command re-assignment

[dana]

Daniel's recent message to zsh-users got me experimenting with the use of tied
parameters in 'pre-command' re-assignments (i.e., the `foo=bar baz` form of
command).

I found that, in 5.4.1 and 5.4.2-dev, tied parameters are not restored correctly
to their previous values if re-assigned in this way after calling a shell
function or built-in:

  % typeset -T SCA arr
  % arr=( a b )
  % arr=( b c ) typeset -p SCA
  typeset SCA=b:c
  % typeset -p SCA
  typeset: no such variable: SCA

(It works the other way around too — with `SCA=b:c ...` it will unset arr.)

It seems that the restoration process simply doesn't concern itself with tied
parameters. It unsets the other parameter, but then there's nothing there to set
it back. I wasn't successful in trying to figure out exactly where it could be
fixed, but i see at least that the reason it unsets the other parameter is the
call to unsetparam_pm() in restore_params().

This doesn't happen when calling external commands, since the restoration isn't
relevant there. However, i also don't get the behaviour that i expect (which is
the scalar being passed down through the environment):

  % typeset -T SCA arr
  % arr=( a b )
  % arr=( b c ) zsh -fc 'print -r -- ${SCA:--}'
  -
  % typeset -p SCA
  typeset SCA=a:b

I guess that's probably a separate thing though.

Anyway, kind of esoteric, but idk, seems like misbehaviour.

dana

Re: [BUG] Tied parameters not restored correctly after pre-command re-assignment

[Bart Schaefer]

On Fri, Dec 8, 2017 at 2:51 PM, dana <dana@dana.is> wrote:
>
> I found that, in 5.4.1 and 5.4.2-dev, tied parameters are not restored correctly
> to their previous values if re-assigned in this way after calling a shell
> function or built-in

Several things:  One, there's no implication that assigning to the
array part of a tied variable will have any effect on the environment
value of the scalar part unless you've explicitly exported the scalar.
  Two, exporting arrays is unsupported / undefined behavior, so using
an array assignment as a command prefix is only sensible in contexts
where all the execution takes place within the current shell (except
see also item one).  Three, if POSIX_BUILTINS is set there are
different rules for how prefix assignments are handled for certain
builtins vs. other cases, so you can't generalize from any particular
experiment.

% which printenv
/usr/bin/printenv
% typeset -xT ABC abc
% abc=(a b c) printenv ABC
a:b:c
% typeset -p ABC
export ABC=''
% typeset -T CBA cba
% cba=(c b a) printenv CBA
%


>   % arr=( b c ) typeset -p SCA
>   typeset SCA=b:c
>   % typeset -p SCA
>   typeset: no such variable: SCA

This works correctly if POSIX_BUILTINS is set, so I would guess it has
some relation to the thread on zsh-workers about "local -r path".

Re: [BUG] Tied parameters not restored correctly after pre-command re-assignment

[dana]

On 8 Dec 2017, at 18:23, Bart Schaefer <schaefer@brasslantern.com> wrote:
> Several things:  One, there's no implication that assigning to the
> array part of a tied variable will have any effect on the environment
> value of the scalar part unless you've explicitly exported the scalar.
>  Two, exporting arrays is unsupported / undefined behavior, so using
> an array assignment as a command prefix is only sensible in contexts
> where all the execution takes place within the current shell (except
> see also item one).

Yeah, i certainly wouldn't expect it to be able to export the array part.

As far as implying an effect on the environment, i don't know, it obviously
doesn't contradict the documentation or anything, but it seems intuitive (and
useful) to me that it would behave that way. But i realise that would be an
enhancement, not a bug.