Unset special parameters

Unset special parameters

[Frank Terbeck]

Hi list,

Since commit f3e7cfe47c32a23, some special parameters are initialised to
be unset. Among them PS1 and RPS1. Which means that prompt-themes need
to mark these parameters as global, because otherwise shells running
with ‘warn_create_global’ set will complain.

When I was trying to do that in my own theme, I was first trying this
(quite simplified):

#+BEGIN_SRC shell-script
prompt_ft_precmd () {
    # ...
    typeset -g RPS1
    RPS1='foo'
    # ...
}
#+END_SRC

...which still triggers the warning. Only when I assign a value to RPS1
in the typeset call, the warning goes away:

#+BEGIN_SRC shell-script
prompt_ft_precmd () {
    # ...
    typeset -g RPS1='foo'
    # ...
}
#+END_SRC

Is this a bug? Because, if I do this with a non-special parameter, it
works the way I'd expect it to:

[snip]
zsh% foo () {
    typeset -g BAR
    BAR=thingy
}
zsh% foo
zsh% echo $BAR
thingy
[snap]


Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: Unset special parameters

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

On Mon, Feb 10, 2014 at 8:08 AM, Frank Terbeck <ft@bewatermyfriend.org>wrote:

> Hi list,
>
> Since commit f3e7cfe47c32a23, some special parameters are initialised to
> be unset. Among them PS1 and RPS1. Which means that prompt-themes need
> to mark these parameters as global, because otherwise shells running
> with 'warn_create_global' set will complain.
>

Hrm, I never remember about that option.  Definitely an unforeseen
side-effect, and possibly a reason to back out some of those changes.
 Compare my mention of breakage if e.g. OPTIND is declared unset.


> prompt_ft_precmd () {
>     # ...
>     typeset -g RPS1
>     RPS1='foo'
>     # ...
> }
>
> ...which still triggers the warning.


Hmm.  Consider this:

  dfn_xyz() { typeset -g XYZ; unset XYZ; XYZ=foo }

dfn_xyz prints the warning, because "typeset -g XYZ" has only caused XYZ to
"exist" until the point at which it is unset again.  Is this also a bug?

If instead I do

  dfnset_xyz() { typeset -g XYZ=123; unset XYZ; XYZ=foo }

dfnset_xyz does NOT give the warning, because assigning in typeset has
caused the variable to become a "real" global which survives the unset.

An analogous thing is going on here with RPS1.  It already exists but in an
unset state; typeset -g without an assignment doesn't cause it to reappear,
so you get the warning when assigning to it.  (On the other hand "typeset
-g" of a nonspecial DOES cause it to reappear, that's one of the
differences in the handling of a special.)

Probably this means startparamscope() has to do something differently with
specials that have PM_UNSET.