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

[Rocky Bernstein <rocky.bernstein@xxxxxxxxx>]

On Tue, Mar 1, 2011 at 10:15 AM, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>wrote:

> 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? :-)
>

You seemed to interpret this as:
  don't (understand or disagree)
rather than the intended:
   (don't understand) or (disagree)

But to simplify it for you: I disagree.

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's always the case that in any point in the program zsh is accessing
variables that were defined *somewhere* on the call chain. zsh and
programmers don't collapse under the heavy weight of this complexity :-)

Rather, you inspect and assign to variables and the values come from the
right dynamic binding according to consistent rules and get put back to the
right dynamic scope as long as you don't issue some sort of redefinition
statement.



>  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.)


> 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 are greatly over-reacting here. Most zsh programs in fact don't use
associative arrays. And this is only a "problem" when you want to create
something new. The only situation that I can think of where you would want
to do this is if you had misspelled an associative array name. But if that's
the case, I suggest you use the handy debugger command called "restart"
after correcting the mistake.



> Hence "doomed" -- it's literally impossible to guarantee that you can
> store variable state


Again a gross exaggeration.  One doesn't have to be perfect *all* the time
to be helpful in *most* situations. Given two options of limiting choices to
only those things that work perfectly versus the option of allowing some
imperfection but often being helpful, guess which option I prefer?  In the
one case one is "doomed" to get nothing done. In the other case you make a
start at solving problems. Furthermore, as you go along, you realize how to
improve.

For example, I'm now considering automatic save back of changed variables as
an option, since I probably will maintain a list of those variables anyway.

I won't go into the areas where various simulations inside a debugger fail.
And those areas also extend to the bash debugger. By the way, ksh has more
control over setting scope.

But suffice it to say, in my use, I've never run into a practical case where
I have encountered any of these discrepancies which caused confusion or
prevented me from fixing a bug in using either the zsh or bash debuggers.
Furthermore, I've yet to have anyone else report that they've noticed the
long-known discrepancies. Still, I've been a been able to use both debuggers
to write significant code and solve real problems. And so have others.


> ....
> but you
> must be working in a more constrained context than I'm imagining.
>

And that's the difference -  I'm coming from this from use and experience
rather than guessing at how the debugger is used and the kinds of
problems one encounters.