Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site wang.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!wanginst!wang!ephraim
From: ephraim@wang.UUCP (pri=8 Ephraim Vishniac x76659 ms1459)
Newsgroups: net.micro.mac
Subject: Re: HFS problems
Message-ID: <788@wang.UUCP>
Date: Thu, 3-Apr-86 15:14:55 EST
Article-I.D.: wang.788
Posted: Thu Apr  3 15:14:55 1986
Date-Received: Sat, 5-Apr-86 11:31:51 EST
References: <184@tekchips.UUCP>
Organization: Wang Labs, Lowell MA
Lines: 26

Chip Schnarel writes:
> One solution to the [HFS] problem is to make every program search up and
> down the file folder structure until it finds the file or exhausts the
> system.  This solution is not very efficient at best.
> 
> [But in Rascal] there is a string
> resource which tells the RASCAL compiler where the libraries are.  Just edit
> the resource to give the explicit location of the library folder.  RASCAL now
> works fine.
> 
> Example:
>   Libraries:SomeVolume:SomeFolder:SubFolder:LibraryFolder
>   Utilities:SomeOtherVolume:DifferentFolder:FolderInFolder:...:UtilitiesFolder
> 
> Now Unix hackers will tell you, correctly, that it is bad practice to hard
> code this sort of info into the application.  What happens when you run the
> app. on another system with the Libs in a different place?  Here is a use
> where resources show thier strength!  The info is not "hard coded in" it is
> an editable part of the application configuration.  A reasonable solution I
> believe.

I think a better solution is to use the path name if it exists, then fall
back to exhaustive search (after warning the user?) if there's no path name
or the files aren't there.  Once the files are found, the application can
update its own PATH resources.  Alernatively, the user could be asked to 
point out the correct folder and then be given a choice of using this path once or permanently (i.e., reconfiguring).