Re: Unset special parameters

[Bart Schaefer <schaefer@brasslantern.com>]

[-- 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.