Re: typeset -p output gives shows variables which can't be read back in

[Bart Schaefer <schaefer@brasslantern.com>]

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.