* Unset special parameters
@ 2014-02-10 16:08 Frank Terbeck
2014-02-10 20:24 ` Bart Schaefer
0 siblings, 1 reply; 2+ messages in thread
From: Frank Terbeck @ 2014-02-10 16:08 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Unset special parameters
2014-02-10 16:08 Unset special parameters Frank Terbeck
@ 2014-02-10 20:24 ` Bart Schaefer
0 siblings, 0 replies; 2+ messages in thread
From: Bart Schaefer @ 2014-02-10 20:24 UTC (permalink / raw)
To: Zsh hackers list
[-- 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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-02-10 20:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-10 16:08 Unset special parameters Frank Terbeck
2014-02-10 20:24 ` Bart Schaefer
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).