zsh-workers
 help / color / mirror / code / Atom feed
* Nested shell command in zshdb (Was Re: typeset -p output gives shows variables which can't be read back in)
@ 2011-03-01 16:13 Rocky Bernstein
  2011-03-01 16:57 ` Bart Schaefer
  0 siblings, 1 reply; 2+ messages in thread
From: Rocky Bernstein @ 2011-03-01 16:13 UTC (permalink / raw)
  To: zsh-workers

[-- Attachment #1: Type: text/plain, Size: 3528 bytes --]

On Tue, Mar 1, 2011 at 10:15 AM, Bart Schaefer <schaefer@brasslantern.com>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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Nested shell command in zshdb (Was Re: typeset -p output gives shows variables which can't be read back in)
  2011-03-01 16:13 Nested shell command in zshdb (Was Re: typeset -p output gives shows variables which can't be read back in) Rocky Bernstein
@ 2011-03-01 16:57 ` Bart Schaefer
  0 siblings, 0 replies; 2+ messages in thread
From: Bart Schaefer @ 2011-03-01 16:57 UTC (permalink / raw)
  To: zsh-workers

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-03-01 16:58 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-01 16:13 Nested shell command in zshdb (Was Re: typeset -p output gives shows variables which can't be read back in) Rocky Bernstein
2011-03-01 16:57 ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).