From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28772 invoked by alias); 4 Dec 2015 17:57:06 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 37310 Received: (qmail 4941 invoked from network); 4 Dec 2015 17:57:03 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-AuditID: cbfec7f5-f79b16d000005389-e8-5661d3ec6265 Date: Fri, 04 Dec 2015 17:56:56 +0000 From: Peter Stephenson To: Zsh Hackers' List Subject: Re: PATCH: Ghastly typeset -p array hack finally bites the dust Message-id: <20151204175656.6291faeb@pwslap01u.europe.root.pri> In-reply-to: <151204092923.ZM16137@torch.brasslantern.com> References: <20151204153421.5771f9ce@pwslap01u.europe.root.pri> <151204092923.ZM16137@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsVy+t/xy7pvLieGGXyeyG9xsPkhkwOjx6qD H5gCGKO4bFJSczLLUov07RK4MhYubWApeMldcbRhLXMD4x3OLkZODgkBE4lDBzcwQ9hiEhfu rWfrYuTiEBJYyiix59lvJpCEkMAMJolNi7QhEqcZJT5/mwFVdYZR4sbrqSwgVSwCqhJv5l8H 62ATMJSYumk2YxcjB4eIgLZE+0cxEFNYwEPi+1sNkApeAXuJA7vugS3mFLCSWLdxDyPErnyJ xo/LwGx+AX2Jq38/MUEcZy8x88oZRoheQYkfk++BbWUW0JLYvK2JFcKWl9i85i0zxBx1iRt3 d7NPYBSehaRlFpKWWUhaFjAyr2IUTS1NLihOSs810itOzC0uzUvXS87P3cQICeWvOxiXHrM6 xCjAwajEw8uwKSFMiDWxrLgy9xCjBAezkggvs0ximBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHe mbvehwgJpCeWpGanphakFsFkmTg4pRoYHRft+3dcR4T5ntT7awzvIo+9WjZplvo73nsT1v7L vbVKsueIrvnq6ycndi1avpCHcevPmRccYwz3OhX03r/KtoFl2t+ihAbRjAjmX/tDM37v452e KnT24Fzv3a4ej09V7OE4v//xaufgpdVdVUF3773gn+epF5n+KFLPPjKvryx77nMZK27W80os xRmJhlrMRcWJAMN3sfJhAgAA On Fri, 04 Dec 2015 09:29:23 -0800 Bart Schaefer 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