From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eplet.mira.net.au (eplet.mira.net.au [203.9.190.17]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id WAA14388 for ; Fri, 12 Jul 1996 22:38:24 +1000 (EST) Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by eplet.mira.net.au (8.7.5/8.7.3) with ESMTP id WAA14253 for ; Fri, 12 Jul 1996 22:38:21 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id IAA09735; Fri, 12 Jul 1996 08:18:35 -0400 (EDT) Resent-Date: Fri, 12 Jul 1996 08:18:35 -0400 (EDT) Message-Id: <199607121217.OAA05821@hydra.ifh.de> To: zsh-workers@math.gatech.edu Subject: Re: Bug Report: Env Vars and shell functions In-reply-to: "aheading@jpmorgan.com"'s message of "Thu, 11 Jul 1996 23:11:24 MET." <199607112211.XAA18522@et-sun4.uk.jpmorgan.com> Date: Fri, 12 Jul 1996 14:17:34 +0200 From: Peter Stephenson Resent-Message-ID: <"Ldbyg3.0.1O2.QAavn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1620 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu aheading@jpmorgan.com wrote: > On a related note, should the following not restore IFS? > > sun4% IFS=@ set a@b@c@d; echo $IFS > @ This is a very ancient, revered and traditional bug, handed down since time immemorial from the hand of pfalstad himself. Special parameters aren't restored after builtin constructs, unlike other parameters (at least, after Zoltan's recent patches). The problem is that there are numerous different ways for setting builtins, and to do this properly would mean save/restore functions for each. One hack (actually, that's unfair --- I've used more or less the same trick in a C++ parameter-reading class with templated virtual functions, relying only on the presence of insertors and extractors for the type in question, and it works vey nicely) that might work here with a lot of parameters (but not such as SECONDS, which would really need its own functions) is to retrieve the parameter as a string value with the function used with $VAR for printing, getstrvalue(), store that, then call the function that sets the parameter from a string supplied on the command line with VAR=..., setsparam(). This would do the trick reasonably simply for things like PATH and IFS. Probably care is needed, e.g. you can forget this for arrays and what do you do if someone tries it with $path or $cdpath? Any comments? Any implementations??? > And finally, why doesn't this work? > sun4% local x=($(date)) > zsh: not an identifier: 10 BST 1996) Do you mean, why can't you assign arrays from `local'? I don't see any prospect of doing it like that, since you would need special parsing of the stuff in parentheses, which is somewhat abhorrent for something that's supposed to look like an ordinary command; passing the argument as a single word gets you into problems of how to split it later --- and in the case shown, you still need special parsing to avoid getting the expansion local x=Fri Jul 12 14:12:47 MET 1996 with fully-paid-up spaces between the arguments, which is what is currently (and correctly) happening. (Csh does special parsing after `set', 'nuff said). It should, however, definitely be possible to do the equivalent of `set -A' with local or typeset, but it isn't. This is very nearly a bug. Actually, I don't quite understand that error message, since it suggests the last few words are passed as one, which isn't happening to me. -- Peter Stephenson Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77330 Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, 15735 Zeuthen, Germany.