Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!agate!eris.berkeley.edu!mwm
From: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer)
Newsgroups: comp.sys.amiga.tech
Subject: Links vs. aliases
Message-ID: <1989Sep9.080227.14162@agate.uucp>
Date: 9 Sep 89 08:02:27 GMT
References: <19644@gryphon.COM>
Sender: usenet@agate.uucp (USENET Administrator;;;;ZU44)
Reply-To: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer)
Organization: Missionaria Phonibalonica
Lines: 29

In article <19644@gryphon.COM> ddave@pnet02.gryphon.com (David Donley) writes:
<Links still don't work as very good aliases,

This is the most cogent statement on the subject yet. The converse is
also true - aliases don't make very good links.

Links don't make good aliases because aliases can supply arguments or
flags; using links to do that requires changing the program (Dave
mentioned this).

Aliases don't make good links because links provide a new name for a
file in the file system. This will be visible from inside of programs
- for instance, if provided on an arg line.

As for speed - an alias will almost always be slower than a (hard)
link when they do the same thing. This is because invoking the alias
will cause all the work that invoking the link would, plus having to
do the alias replacement. Of course, implementation details can change
this (i.e. - linear search of an alias list, intead of something
intelligent; aliases that are absolute path names; so many links that
the directory adds blocks, soft links instead of hard, etc.).

	<mike

--
Il brilgue: les toves lubricilleux			Mike Meyer
Se gyrent en vrillant dans le guave,			mwm@berkeley.edu
Enmimes sont les gougebosqueux,				ucbvax!mwm
Et le momerade horsgrave.				mwm@ucbjade.BITNET