Re: PATCH: Ghastly typeset -p array hack finally bites the dust

[Peter Stephenson <p.stephenson@samsung.com>]

On Fri, 04 Dec 2015 09:29:23 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> So we're just going to ignore the possibility that the typeset keyword
> has been disabled?

Yes, I think it's a "so don't do that, then".  We don't generally check
if something's enabled before outputting code that uses it.  Also, there
are already assumptions built into the use of "typeset -p" output that
the shell is in a pristine state e.g. the readonly parameters don't yet
exist.

> I'm fine with that, as long as it's explicitly acknowledged.  Also the doc
> should contain a warning about this side-effect of disable, someplace.

diff --git a/Doc/Zsh/builtins.yo b/Doc/Zsh/builtins.yo
index 49806e4..120ec82 100644
--- a/Doc/Zsh/builtins.yo
+++ b/Doc/Zsh/builtins.yo
@@ -1812,7 +1812,10 @@ this means.
 Note that each interface to any of the commands my be disabled
 separately.  For example, `tt(disable -r typeset)' disables the reserved
 word interface to tt(typeset), exposing the builtin interface, while
-`tt(disable typeset)' disables the builtin.
+`tt(disable typeset)' disables the builtin.  Note that disabling the
+reserved word interface for tt(typeset) may cause problems with the
+output of `tt(typeset -p)', which assumes the reserved word interface is
+available in order to restore array and associative array values.
 
 If the shell option tt(TYPESET_SILENT) is not set, for each remaining
 var(name) that refers to a parameter that is already set, the name and

pws