From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8964 invoked by alias); 1 Mar 2011 03:09:57 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28822 Received: (qmail 7493 invoked from network); 1 Mar 2011 03:09:44 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 209.85.161.171 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sTIYntHxlgGXuQDDH2DgYVSINXH25mh4odYC202sa6I=; b=Lhe7Tn7C+JErSNcqM3tsGHOZ6qAy+5rLgAnTFNj8CMPw1lYcPDtlU+RHUZVZigLwRS +uXL07QiefbA9kMe15HK01s9joHtHHvrG0LDH3Z0xfmX7ZVRLquLrILlwrMlakz9F0Er AMV0Bny0+gLM9ZTiZsrgQG5IAUETpUogBSsrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pRAzOxiZsW6hk8fTvUwWMecZwxrY/RkcGv6WD5cOB0ihNHfhXWIG7q4SEIBlzX+vGg HC2/bPaXlVB233sGZ8gSzTA8Rre/D50iQ50luEWkAlkC6GhscXHBqOJdwq3hSD00U3NO I9iE3+QghpkrVKLOz4FjX/ughfWlkxBYzfTQI= MIME-Version: 1.0 In-Reply-To: <110227230923.ZM5385@torch.brasslantern.com> References: <110227130132.ZM4792@torch.brasslantern.com> <110227230923.ZM5385@torch.brasslantern.com> Date: Mon, 28 Feb 2011 22:09:37 -0500 Message-ID: Subject: Re: typeset -p output gives shows variables which can't be read back in From: Rocky Bernstein To: Bart Schaefer Cc: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary=000e0cd6a9ce5d1093049d6320e2 --000e0cd6a9ce5d1093049d6320e2 Content-Type: text/plain; charset=ISO-8859-1 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 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@brasslantern.com>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). > --000e0cd6a9ce5d1093049d6320e2--