Re: uppercase inheritance

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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