Re: Nested shell command in zshdb (Was Re: typeset -p output gives shows variables which can't be read back in)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 1, 11:13am, Rocky Bernstein wrote:
}
} On Tue, Mar 1, 2011 at 10:15 AM, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>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.