Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!usc!hacgate!tcville!sed170!lee
From: lee@sed170.HAC.COM (John Lee )
Newsgroups: comp.sys.amiga.tech
Subject: Re: yet another 1.4 request
Message-ID: <294@sed170.HAC.COM>
Date: 29 Jun 89 23:52:47 GMT
References: <0933.AA0933@caleb> <1989Jun16.151408.8382@ziebmef.uucp> <3940@sugar.hackercorp.com> <19856@cup.portal.com>
Reply-To: lee@sed170.UUCP (John Lee (ird))
Organization: Hughes Aircraft Co., El Segundo, CA
Lines: 53
Distribution:


In article <19856@cup.portal.com> you write:
[...]
>Anybody out there want to suggest a half-dozen or so uses for a
>soft link?  And maybe a few for a hard link?  I can think of some
>trivial uses but what do you really need 'em for?
>
>Dana  
>
>(thankx)

I have a use for soft-links I use almost every day.  My current project
involves the X11 Toolkit and the header files every module requires resides
in /usr/include/X11, so that #includes look like:

	#include <X11/another_header.h>

I'm developing widgets, so I'm constantly creating/deleting/modifying these
header files, so I have them in my own subdirectory ~/wrk/X11.  Since the "<>"
format means the directory /usr/include, the #includes I use look like:

	#include "X11/another_header.h"

which will look in /usr/include after looking at my directory first, so even if
the header is in /usr/include/X11, things still work.

Still with me?  Good.  Here's where soft-links are absolutely necessary:
Because of the object-oriented hierchy of the toolkit, most of those headers
need to include other headers in the X11 directory.  That means that I must
have a soft-link in ~/wrk/X11 to itself.  Without it,  I would need to know and
manually include the headers for every object above the object I'm dealing
with in the hierchy and it would be a *BIG* mess or even impossible.

But that's not all.  Soft-links allows a file to appear in multiple directories
yet when a change in the file is needed, only the actual files needs to be
updated--the links are updated "automatically".  One can also restrict
access such that links can only read the file and not write to it.  While this
doesn't appear particularly useful, it's very handy on a multi-user machine
where multiple programmers need to share files but have each file changeable
by only one person.  Programmers don't have to hardcode full paths for each
file in another person's directory.  They just link to the file in the foreign
directory and use it as if it were in their (sub)directory.  It's useful for
team projects and classes.

It's not too hard to envision similar situations for a user or programmer on
an Amiga, and the above are by no means a complete list.
-------------------------------------------------------------------------------
Raining CATS and DOGS?  Join the RATS: Remote Amiga Teleconferencing System
	+--------+			John Lee
	| HUGHES |
	+--------+			ARPAnet: jhlee@hac2arpa.hac.com	
	Hughes Aircraft Company
The above opinions are those of the user and not of those of this machine.