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

[Rocky Bernstein <rocky.bernstein@xxxxxxxxx>]

Comments in line. In sum, thanks again for the code suggestion. A modified
version of that I now use in the debugger.

On Mon, Feb 28, 2011 at 2:09 AM, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>wrote:

> On Feb 28, 12:08am, Rocky Bernstein wrote:
> }
> } As for the typeset -T and typeset -p not showing -T associations, I think
> } that's a misfeature.
> }
> } Should I look into providing a patch for this?
>
> I think first there needs to be a bit of discussion about what the result
> should look like.
>
> E.g. if I have
>
>    typeset -T SCALAR=x:y:z array
>
> and then I do
>
>    typeset -p SCALAR
>    typeset -p array
>
> should I get the exact same output both times?
>

I don't understand the complexity let alone the ramifications here. If you
think it worthwhile or if others may be as confused as I am please
elaborate. (But I am probably not qualified to judge.)

In my simple-minded way of thinking, if I had previously issued:
   typeset -T SCALAR=x:y:z array

then "typeset -p" I would imagine would print:
   typeset -T SCALAR=x:y:z array

what "typeset -p array" prints is another issue and dependent on the
definition of "array".



> Also what should the value of $parameters[foo] look like?  My first idea
> is something like
>
>    array-tied:FOO
>
> but there may be problems with that which I haven't foreseen.
>

Again, you are probably in a better position than most to know about those
problems. I imagine if anyone else on the list has something to add, they
will.

From my standpoint, even if nothing is done here but just adding the
simple-minded "typeset -p" for the tied array/scalar is an improvement.



> } Saving an environment for reloading into another session, whether
> } nested or not, might be useful in other contexts. Possibly the code
> } you or I have in zshdb could be turned into a function and put inside
> } the parameter module?
>
> Until you mentioned the debugger, I was completely at a loss to come up
> with an environment where you'd want to attempt to reload any parameter
> that is normally maintained by the shell internals (such as any of the
> variables in the $parameter module, or most of the other modules for
> that matter).  I still can't think of one.
>

Alas again I am not sure I understand you here.

Something I think likely is that I am inside a zsh session I've been playing
around writing definitions and trying tests and setting variables and want
to save out the environment so that sometime later I can come back into zsh
and set things up roughly as they were before.

Or perhaps in order to send back a bug report I want someone else to be able
to see the
relations of things. They might have to edit parts of that environment, but
still the bulk of the settings would be relevant.


> However, parameters that are marked "typeset -H" and thus have their
> values suppressed in the typeset -p output can only be saved/restored
> by tricks that would be better applied in a C function, so I can't
> really argue against it.
>
> } What I'm thinking of now is adding a function save_var which takes the
> } name of a variable one wants to persist.
>
> That makes a bit more sense, but in that case you have a list of the
> names and can do
>
>    for param in "${save_vars[@]}"
>    do case $parameters[$param] in
>       (*assoc*)
>         print -- "typeset -A $param; $param=( ${(P@kvqq)param} )";;
>       (*array*)
>         print -- "typeset -a $param; $param=( ${(P@qq)param} )";;
>       # etc.
>    done > $the_save_file
>
> The point being that one doesn't need to dump the entire output of
> typeset, only the parameters whose names are explicitly known.
>

I never suggested on a *restore* everything would be saved, although now
that I think of it, that would have the advantage of obviating having the
user indicate which variables should persist.

For now, I'll go with the more manual approach. It may in fact be that folks
*don't* want changes they make to persist. Thing can always be changed
later.

I am kind of mixed on how much I want to use zsh-specific idioms, rather
than, say using
eval which may be clunkier but works on all of the POSIX shells. The more
shell-specific code I have, the more maintenance I have across the 3 POSIX
shell debuggers.

That said, the code you have above is more shell idiomatic than the kind of
thing I have been writing. I suspect there is much that could be improved in
the debugger because at heart I'm not that good of a POSIX shell
programmer.

I hope you don't take offense, but the code you have above is a little bit
wrong. We don't want to issue typeset commands because that will cause the
*scope* to change.

In a debugger, one is in trap function which then invoked the nested shell.
The restore is done in the trap hook -- specifically in the debugger's
"shell" command. But the original definition of the variable (if there is
one) that a programmer typically wants to change will not be in the hook,
but farther away the call chain in the debugged program.


> } If there is something like a tie function like there is in Perl or a
> } discipline function on a varaible like ksh, that might be used, but
> } this would be on a per-variable basis.
>
> There's not, at this time.
>
> } On Sun, Feb 27, 2011 at 4:01 PM, Bart Schaefer <
> schaefer@xxxxxxxxxxxxxxxx>wrote:
> } >
> } >    () {
> } >      local param type
> } >      for param type in "${(kv@)parameters}"
> } >      do
> } >        case "$type" in
> } >        (*local*) continue;;   # Skip loop variables
> } >        (*export*) continue;;  # No need to dump/restore if exported?
> } >        (*special*) continue;; # Maintained by the shell
> } >        (*readonly*) continue;;
> } >        (*) typeset -p "$param";;
> } >        esac
> } >      done
> } >    }
> }
> } But while we are being precise, let me point out that it is wrong to
> } say that a local variable is a "loop" variable as you suggest in the
> } code above.
>
> I was referring to skipping "param" and "type", the variables for the loop
> over ${(kv)parameters}.  There aren't any other locals in the anonymous
> scope (though there could be in a surrounding scope).
>