Re: Parameter aliasing? RE: PATCH: "typeset -m" plays havoc

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sep 18, 12:40pm, Andrej Borsenkow wrote:
} Subject: Parameter aliasing? RE: PATCH: "typeset -m" plays havoc
}
} > >     erase_PS1() { typeset PS1 prompt PROMPT }
} 
} The only clean general way to do it is to introduce real aliases
} instead of separate parameters internally referencing the same value.

How about this as an alternate solution:  Along with the shared pointer
for the value of the "tied" parameters, keep track of the locallevel
whenever any one of the parameters is made local.  When unwinding, only
reset the shared pointer if the tracked locallevel is >= the current
locallevel, and in that case also reset the tracked locallevel to one
less than the current locallevel.  That way, all the "tied" parameters
are reset at most once as each function is unwound.

(I note in passing that parameters created with `typeset -T' become un-
tied when either of them is made local, but special tied parameters like
path/PATH do not.)

} [With aliases] first typeset would save original value and two others
} would simply do nothing (well, they would actually print parameters
} value. But there is no real way to avoid it).

I'm not very happy about this idea, particularly if there's no way to
avoid that side-effect.  If it can't be made to work "as if" there are
separate but "tied" parameters, I'd rather keep hunting for another
solution.  It sounds like it has a lot of potential to interact badly
with the PM_HIDE mechanism, too.

Using `typeset -h' is a workaround for the problem, by the way:

    test_PS1() {
	typeset -h prompt PROMPT
	typeset PS1
    }

As to these issues:

} One point to decide is: should 'unset alias' remove parameter itself
} (with all aliases) or just unset current alias?

There's a bigger question than that:  Which name *is* "the parameter
itself" and which are merely aliases?  Or are none of them really the
parameter?

It can't just unset the alias, because the shell has to behave "as if"
the parameter really were unset; e.g., if you unset PROMPT, zsh should
stop printing a top-level prompt, until such time as you assign to one
of PS1, prompt, or PROMPT.  It can't "forget about" the alias, because
`unset PROMPT; PROMPT=foo' has to retain the side-effect of `PS1=foo'.

It's an incompatible change to unset them all when any of them is unset,
though realistically, probably not a change that anyone would notice.

} And if we want user-defined aliases?

If we're going to go that way, we should implement ksh namerefs instead.
(Except I don't know what happens when you assign to a nameref; does it
assign to the referenced variable, or change the name to which the ref
refers?)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net