Path: utzoo!attcan!uunet!van-bc!skl
From: skl@van-bc.UUCP (Samuel Lam)
Newsgroups: comp.mail.elm
Subject: Re: System aliases
Summary: Scopes and bindings of the various levels of aliases.
Keywords: ELM, aliases.
Message-ID: <210@van-bc.UUCP>
Date: 31 Jul 89 09:03:38 GMT
References: <509@wubios.wustl.edu> <177@van-bc.UUCP> <1023@isaak.UUCP> <203@van-bc.UUCP> <1989Jul30.013125.7407@lokkur.dexter.mi.us>
Organization: Balliffe International, Vancouver, B.C., Canada
Lines: 41


 In article <1989Jul30.013125.7407@lokkur.dexter.mi.us>, scs@lokkur.dexter.mi.us
  (Steve Simmons) wrote:
 >In article <203@van-bc.UUCP>, I wrote:
 >>In article <1023@isaak.UUCP>, woerz@isaak.UUCP (Dieter Woerz) wrote:
 >>>There is still a problem. Asume you have the following system alias
 >>>file:
 >>>    allusers =  All users of this host  =   a, b, c, d, e, f
 >>>and the sender of the message has the following in his personal
 >>>aliases file:
 >>>    c = ... =   c@x.y.z
 >>>Then the c@x.y.z get the message that should have reached c on the
 >>>local machine.
 >
 >>If that's the case, then shouldn't the current behaviour of this be
 >>consider broken?  My argument here is that when the system administrator
 >>makes up the system aliases file, there would be no way for him to
 >>predict how the system aliases would later expand IF each user's private
 >>aliases file is also taken into consideration during the later expansion.
 >>If there is no way to predict how a system alias is going to expand, then
 >>what good is it to have system aliases (that's unpredictable).
 >
 >...  Any time there is a heirarchy of aliases, it is possible for
 >lower level aliases to "mask off" upper level ones.  Pretty similar to
 >programming languages which allow nesting.

It would actually be reasonable for an higher (user) level alias to mask
out a lower (system) level one when trying to match an alias which the user
had entered interactively, since the interactive user is considered to be at
the inner most scope (in the programming language sense).

However, when expanding system aliases, we should consider the context
in which they are created it.  Since system aliases is created at the
outer scope, it has no user alises to bind to at the time of its creation,
and thus should only use other system aliases when it is being expanded.
Otherwise it would render the run-time expansions of system aliases to
be random and unpredictable, and thus making the system aliases feature
rather undependable.

-- 
Samuel Lam     {alberta,watmath,uw-beaver,cs.ubc.ca}!ubc-cs!van-bc!skl