From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19869 invoked from network); 11 Dec 1999 21:20:28 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Dec 1999 21:20:28 -0000 Received: (qmail 13569 invoked by alias); 11 Dec 1999 21:20:18 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9000 Received: (qmail 13557 invoked from network); 11 Dec 1999 21:20:16 -0000 From: "Bart Schaefer" Message-Id: <991211212001.ZM30518@candle.brasslantern.com> Date: Sat, 11 Dec 1999 21:20:01 +0000 In-Reply-To: Comments: In reply to Peter Stephenson "Re: uppercase inheritance" (Dec 10, 9:36pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: Peter Stephenson , zsh-workers@sunsite.auc.dk Subject: Re: uppercase inheritance MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Dec 10, 9:36pm, Peter Stephenson wrote: } Subject: Re: uppercase inheritance } } The problem is that the version in the environment isn't uppercased; } actually, I'm not completely convinced that this is wrong, since the } typeset specifiers are quiet specifically for output formatting When are they noisy? (Sorry.) } not for transformations on the variable itself. I've always wondered about that. What's the point? There's no way to refer to the value except to "output" it. Doing a split or substitute only on lower-case letters and then outputting the result in upper case seems like a rather obscure usage (not to mention potentially confusing) and one that could equally well be accomplished by using a modifier. It makes more sense for justification, so maybe the point is to have it work consistently. However, look at this (3.1.6-pws-11 *before* 8997): zagzig% typeset -u up zagzig% up=case zagzig% typeset +u up zagzig% echo $up CASE zagzig% typeset +u up zagzig% typeset +u zagzig% echo $up CASE zagzig% Note that, although the upcased property has been removed from "up", its value is now *stored* all upper case. This does NOT happen with justify: g% typeset -R 10 just zagzig% just=right zagzig% typeset +R just zagzig% echo "$just" right zagzig% typeset +R just zagzig% typeset +R zagzig% echo "$just" right This makes me believe that case conversion was intended to *appear* as though it happened on assignment, not just on output, but that Paul was too lazy to actually implement it that way. It gets stranger: zagzig% typeset -l down=CASE zagzig% export down zagzig% printenv down CASE zagzig% echo $down case zagzig% typeset +l down zagzig% echo $down case zagzig% printenv down CASE Now watch what happens if we play with "typeset +x": zagzig% unset up down zagzig% typeset -u up zagzig% export up zagzig% up=case zagzig% printenv up case zagzig% echo $up CASE zagzig% typeset +x up zagzig% export up zagzig% printenv up CASE Note that un-exporting and then re-exporting causes the converted value to go into the environment. (Again, this does not happen with justify.) Finally: zagzig% typeset -l down zagzig% down=CASE zagzig% typeset +l down zagzig% echo $down CASE If the value of the variable is never referenced before removing the conversion flag, the stored value remains in the original assigned case rather than being converted. Gaaah. Now if I look at 3.1.6-pws-11 *after* 8997, only these two results have changed: zagzig% typeset -l down=CASE zagzig% export down zagzig% printenv down case zagzig% echo $down case zagzig% typeset +l down zagzig% echo $down case zagzig% printenv down case zagzig% typeset -u up zagzig% export up zagzig% up=case zagzig% printenv up CASE zagzig% echo $up CASE zagzig% typeset +x up zagzig% export up zagzig% printenv up CASE If you decide to fix this, Peter, do you think you could also take care of ksh export semantics (locals *can* be exported in ksh, and the old environ gets restored when they go out of scope) under emulation? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com