From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22727 invoked by alias); 1 Mar 2011 15:15:39 -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: 28826 Received: (qmail 7792 invoked from network); 1 Mar 2011 15:15:37 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110301071520.ZM8224@torch.brasslantern.com> Date: Tue, 01 Mar 2011 07:15:20 -0800 In-reply-to: Comments: In reply to Rocky Bernstein "Re: typeset -p output gives shows variables which can't be read back in" (Mar 1, 1:49am) References: <110227130132.ZM4792@torch.brasslantern.com> <110227230923.ZM5385@torch.brasslantern.com> <110228215959.ZM7435@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: typeset -p output gives shows variables which can't be read back in MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Mar 1, 1:49am, Rocky Bernstein wrote: } } Thanks for the information. The only thing I still don't understand or } disagree with is the "doomed from the start comment". You agree but don't know why? :-) E.g., if the shell you're debugging is six levels deep in function call stack at the point where you decide to break out to a new shell, the variables you dump are going to have several different dynamic scopes which it will be impossible to recreate in the new shell. It will have defined functions which the new shell won't have (though allowing $functions from zsh/parameter to be dumped and restored will get most of them). The option settings may not make sense in a top-level shell and the traps certainly won't be restored. Etc. } In [dynamic] scope, it's sufficient to set the variable somewhere down } the call chain such as in the trace hook and that persists back to } outside the trace hook. I've tested this already in my nested shell } example and it works as expected. But of course here you have to be } careful not to run some sort of command that *defines* the variable } again before the assignment or else that will now be the point of a } new scope for the variable's value. All true, but you can't simply assign to the name of an associative array variable and have it behave like an associative array. You MUST declare it first, and you can't control whether it's already been declared in some surrounding dynamic scope, so even typeset -g is not enough to assure it will persist (and if it's been declared in some surrounding scope, simple assignment will also change it in that scope and not in the global one). Hence "doomed" -- it's literally impossible to guarantee that you can store variable state in a file and then restore it again, even to replicate the state in a new shell. } So although on entry to the nested shell a definition of the type is } either necessary or useful, when writing a file on exit for later } source'ing it is not and is harmful: at the point in the debug hook } where the values are source'd back in to pick up changed values, an } associative array's value has already been defined scope-wise. I'm not sure how you assure the truth of that last statement, but you must be working in a more constrained context than I'm imagining.