Should (t)path = array-unique-special work this way

Should (t)path = array-unique-special work this way

[Sebastian Gniazdowski]

Hello

typeset -U path
PATH="$PATH:/component/nr1"
path+="/component/nr2"
PATH="/component/nr2:$PATH"
print "${(t)path}"
declare -p path


Outputs:
array-unique-special
typeset -a path
path=( /component/nr2 /usr/local/bin /usr/bin /bin /usr/games
/component/nr1 /component/nr2 )

Tested on zsh-5.0.8 and 5.2

Best regards,
Sebastian Gniazdowski

Re: Should (t)path = array-unique-special work this way

[Bart Schaefer]

On Feb 5,  2:45pm, Sebastian Gniazdowski wrote:
}
} typeset -U path
} PATH="$PATH:/component/nr1"
} path+="/component/nr2"
} PATH="/component/nr2:$PATH"
} print "${(t)path}"
} declare -p path

I'm not really sure what question(s) you're asking.

Aside:
 Although it works to append to an array with path+="/component/nr2",
 it's really not good form.  Get used to path+=("/component/nr2") and
 you'll have much less trouble later.

Back to main topic:

} Outputs:
} array-unique-special

So far so good.

} typeset -a path
} path=( /component/nr2 /usr/local/bin /usr/bin /bin /usr/games /component/nr1 /component/nr2 )

For 5.3, this will change to

typeset -a path=( /component/nr2 /usr/local/bin /usr/bin /bin /usr/games /component/nr1 /component/nr2 )

Other things you might be asking about:

Q: Why is nr2 repeated when path is declared -U ?
A: Because it's repeated in $PATH.  Array uniqueness of tied arrays is
   only applied when assigning to the array; when assigning to the tied
   scalar, the array faithfully copies the value of the scalar.  If this
   were not the case, you could end up with a feedback loop (scalar is
   changed -> array uniquifies -> scalar changes again -> etc.).  This
   in turn is because scalars don't have a "uniqueness" property, so if
   the user is explicitly assigning to the scalar then we presume it is
   expected to reflect the value so assigned.

Q: Why doesn't -U appear in the "declare -p" output?
A: Good question.  It doesn't appear for non-special arrays either.  It
   may be intentional because -U isn't a POSIX-supported option, but I
   suspect it's just an accidental omission.

Re: Should (t)path = array-unique-special work this way

[Sebastian Gniazdowski]

On 5 February 2016 at 18:15, Bart Schaefer <schaefer@brasslantern.com> wrote:
> Other things you might be asking about:
>
> Q: Why is nr2 repeated when path is declared -U ?
> A: Because it's repeated in $PATH.  Array uniqueness of tied arrays is
>    only applied when assigning to the array; when assigning to the tied
>    scalar, the array faithfully copies the value of the scalar.

That was my question. The path has *-unique in type, this could be
viewed as a guard that no repetition is possible, but the guard is
avoided by assigning to PATH. That's from one point of view
unexpected.

Side, one lesson is not to rely on attached content and always include
plain question.

Best regards,
Sebastian Gniazdowski

Re: Should (t)path = array-unique-special work this way

[Peter Stephenson]

On Fri, 05 Feb 2016 18:34:06 +0100
Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> That was my question. The path has *-unique in type, this could be
> viewed as a guard that no repetition is possible, but the guard is
> avoided by assigning to PATH. That's from one point of view
> unexpected.

It wasn't your question, but you can of course make PATH unique too, and
I suppose an additional lesson is that for least surprises you might
want always to do

typeset -U path PATH

pws

Re: Should (t)path = array-unique-special work this way

[Peter Stephenson]

On Fri, 5 Feb 2016 17:46:24 +0000
Peter Stephenson <p.stephenson@samsung.com> wrote:
> On Fri, 05 Feb 2016 18:34:06 +0100
> Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> > That was my question. The path has *-unique in type, this could be
> > viewed as a guard that no repetition is possible, but the guard is
> > avoided by assigning to PATH. That's from one point of view
> > unexpected.
> 
> It wasn't your question, but you can of course make PATH unique too, and
> I suppose an additional lesson is that for least surprises you might
> want always to do
> 
> typeset -U path PATH

The behaviour doesn't look like it's documented, at least not in the
obvious place.  The language might be a bit clunky for a shell manual.

diff --git a/Doc/Zsh/builtins.yo b/Doc/Zsh/builtins.yo
index fb630a7..a15f4c2 100644
--- a/Doc/Zsh/builtins.yo
+++ b/Doc/Zsh/builtins.yo
@@ -1980,6 +1980,11 @@ item(tt(-U))(
 For arrays (but not for associative arrays), keep only the first
 occurrence of each duplicated value.  This may also be set for
 colon-separated special parameters like tt(PATH) or tt(FIGNORE), etc.
+Note the flag takes effect on assignment, and the type of the
+variable being assigned to is determinative; for variables with
+shared values it is therefore recommended to set the flag for
+all interfaces, e.g. `tt(typeset -U PATH path)'.
+
 This flag has a different meaning when used with tt(-f); see below.
 )
 item(tt(-Z) [ var(n) ])(

Re: Should (t)path = array-unique-special work this way

[Sebastian Gniazdowski]

On 5 February 2016 at 18:15, Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> Q: Why doesn't -U appear in the "declare -p" output?
> A: Good question.  It doesn't appear for non-special arrays either.  It
>    may be intentional because -U isn't a POSIX-supported option, but I
>    suspect it's just an accidental omission.

Wanted to write a snapshot feature, basically declare -p > snapshot;
setopt typesetsilent; source ./snapshot, but the omission of -U is
quite a blocker. Other interesting thing is that typeset -a a doesn't
fully redefine a, uniqueness still holds if it was present.

% typeset -Ua a
% a=( a a )
% echo ${a[@]}
a
% declare -p > snapshot
% source ./snapshot
% a=( a a )
% echo ${a[@]}
a
% echo ${(t)a}
array-unique
% unset a
% source ./snapshot
% echo ${(t)a}
array
% a=( a a )
% echo ${a[@]}
a a

Best regards,
Sebastian Gniazdowski

Re: Should (t)path = array-unique-special work this way

[Sebastian Gniazdowski]

also:

% echo ${(t)ZPLG_COMPLETIONS_DIR}
scalar
% echo ${parameters[ZPLG_COMPLETIONS_DIR]}
scalar-hideval
% declare -p ZPLG_COMPLETIONS_DIR
typeset ZPLG_COMPLETIONS_DIR

It's declared with typeset -gH

Best regards,
Sebastian Gniazdowski

Re: Should (t)path = array-unique-special work this way

[Daniel Shahaf]

Sebastian Gniazdowski wrote on Sun, Feb 14, 2016 at 11:04:02 +0100:
> On 5 February 2016 at 18:15, Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > Q: Why doesn't -U appear in the "declare -p" output?
> > A: Good question.  It doesn't appear for non-special arrays either.  It
> >    may be intentional because -U isn't a POSIX-supported option, but I
> >    suspect it's just an accidental omission.
> 
> Wanted to write a snapshot feature, basically declare -p > snapshot;
> setopt typesetsilent; source ./snapshot, but the omission of -U is
> quite a blocker. Other interesting thing is that typeset -a a doesn't
> fully redefine a, uniqueness still holds if it was present.

If the parameter already exists, 'typeset' will modify it rather than
replace it.  For example, 'typeset x=foo; readonly x; echo $x' prints
'foo' rather than an empty string.

You might need to call 'unset' before calling 'typeset'?  I'm not sure
whether that has any edgecases to beware of.

Re: Should (t)path = array-unique-special work this way

[Bart Schaefer]

On Feb 14, 11:04am, Sebastian Gniazdowski wrote:
}
} Wanted to write a snapshot feature, basically declare -p > snapshot;
} setopt typesetsilent; source ./snapshot, but the omission of -U is
} quite a blocker.

This doesn't work in the general case anyway, because the output of
"typeset -p" (aka "declare -p") doesn't properly reflect local scopes.
That is, if you're in a local scope, sourcing the "declare -p" output
will create all the variables at that local scope, not at the scopes
where they were originally defined.

In fact it's impossible to correctly reconstruct the local and global
scopes because of the runtime dynamic scoping rules.

Re: Should (t)path = array-unique-special work this way

[Sebastian Gniazdowski]

On 14 February 2016 at 19:44, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Feb 14, 11:04am, Sebastian Gniazdowski wrote:
> }
> } Wanted to write a snapshot feature, basically declare -p > snapshot;
> } setopt typesetsilent; source ./snapshot, but the omission of -U is
> } quite a blocker.
>
> This doesn't work in the general case anyway, because the output of
> "typeset -p" (aka "declare -p") doesn't properly reflect local scopes.
> That is, if you're in a local scope, sourcing the "declare -p" output
> will create all the variables at that local scope, not at the scopes
> where they were originally defined.
>
> In fact it's impossible to correctly reconstruct the local and global
> scopes because of the runtime dynamic scoping rules.

Assuming the feature is for interactive use, what can be the issues
with scopes? I started a new project, worked around limitations of
declare -p with $parameters:

https://github.com/psprint/zsnapshot

It is called in current scope via alias zsnapshot="source snapshot >
snap", the user is informed that he should source output file at
prompt. Are there any possible issues?

(Started this project to face dirt that e.g. a theme can introduce
into session. Before trying a theme that messes up with precmd() and
PS1, one calls snapshot so that he can revert)

Best regards,
Sebastian Gniazdowski