* [BUG] Tied parameters not restored correctly after pre-command re-assignment
@ 2017-12-08 22:51 dana
2017-12-09 0:23 ` Bart Schaefer
0 siblings, 1 reply; 3+ messages in thread
From: dana @ 2017-12-08 22:51 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG] Tied parameters not restored correctly after pre-command re-assignment
2017-12-08 22:51 [BUG] Tied parameters not restored correctly after pre-command re-assignment dana
@ 2017-12-09 0:23 ` Bart Schaefer
2017-12-09 0:47 ` dana
0 siblings, 1 reply; 3+ messages in thread
From: Bart Schaefer @ 2017-12-09 0:23 UTC (permalink / raw)
To: dana; +Cc: zsh-workers
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".
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG] Tied parameters not restored correctly after pre-command re-assignment
2017-12-09 0:23 ` Bart Schaefer
@ 2017-12-09 0:47 ` dana
0 siblings, 0 replies; 3+ messages in thread
From: dana @ 2017-12-09 0:47 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-workers
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-12-09 0:48 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-08 22:51 [BUG] Tied parameters not restored correctly after pre-command re-assignment dana
2017-12-09 0:23 ` Bart Schaefer
2017-12-09 0:47 ` dana
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).