From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23937 invoked by alias); 1 Mar 2011 16:58:15 -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: 28829 Received: (qmail 8258 invoked from network); 1 Mar 2011 16:58:13 -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: <110301085751.ZM8368@torch.brasslantern.com> Date: Tue, 01 Mar 2011 08:57:51 -0800 In-reply-to: Comments: In reply to Rocky Bernstein "Nested shell command in zshdb (Was Re: typeset -p output gives shows variables which can't be read back in)" (Mar 1, 11:13am) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Nested shell command in zshdb (Was 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, 11:13am, Rocky Bernstein wrote: } } On Tue, Mar 1, 2011 at 10:15 AM, Bart Schaefer wrote: } > You agree but don't know why? :-) } } But to simplify it for you: I disagree. Yes, I got that, hence the [ :-) ]. } > It will } > have defined functions which the new shell won't have } } No, I had already handled that from the start and dumped functions via } typeset -pf. (A look at the code would have shown that.) Ah, you seem to think I'm critiquing your debugger, which I'm not. I'm making general statements about the utility of creating a new shell builtin [in the zsh/parameter module] whose sole purpose is to dump the parameter state for later restoration -- and pointing out that it's fiction to pretend that the parameter state can successfully dumped from an arbitrary point in shell execution and then restored at a different arbitrary point (or in a new shell), especially in the absence of all those other things that your debugger does to preserve other aspects of the state. The more constrained context in your debugger is that the dump and restore points are *the same* (modulo a single external command that is run in between), but that says little about the general utility of the specific feature in question. It also doesn't address what the output of "typeset -p" should be, as by definition that must include "typeset" commands which you don't want in your context.