Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 3 Jul 1998 01:40:56 -0400
From:      Garance A Drosihn <drosih@rpi.edu>
To:        Mike Smith <mike@smith.net.au>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Variant Link implementation, continued
Message-ID:  <v04011722b1c21a42b8e0@[128.113.24.47]>
In-Reply-To: <199807030416.VAA03798@antipodes.cdrom.com>
References:  Your message of "Thu, 02 Jul 1998 18:10:44 EDT."             <v0401171bb1c1acb4f7a9@[128.113.24.47]>

next in thread | previous in thread | raw e-mail | index | archive | help
At 9:16 PM -0700 7/2/98, Mike Smith wrote:
> Allowing links to indicate that they *should* be keyed off the
> environment space, OTOH, isn't such a sin.  eg:
>
>  ${sysctl:hw.arch} and ${env:USER}
>
> but this creates a new union space with yet another different
> syntax.
>
>  ${space=sysctl, mib=hw.arch} and ${space=env, var=USER}
>
> perhaps?

Hmm, not quite the strategy I was leaning towards, but I do feel
much less concerned with this than the earlier alternative.  If
the creator of the link really *wants* the link to change based on
an environment value, then any headaches caused are their fault,
and not the implementation's fault.

Something like this would let administrators or system-developers
to use variant symlinks in situations where any value influenced
by the users environment would just be begging for trouble.  Thus,
something long these lines would, I think, make variant symlinks
more useful.

I must admit I don't understand your comment about a "new union
space", so I would lean toward a more terse syntax, such as your
first suggestion.  Perhaps that just proves I should go home and
get some sleep...

---
Garance Alistair Drosehn           =   gad@eclipse.its.rpi.edu
Senior Systems Programmer          or  drosih@rpi.edu
Rensselaer Polytechnic Institute

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04011722b1c21a42b8e0>