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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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?

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

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.

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