🚀 go-pugleaf

From article <346@coma.UUCP>, by axel@coma.UUCP (Axel Mahler):

> No benefits ?! It's a major nuisance to always think of moving those
> f&*%ing resource-files around together with the programs. Separate
> resource files are also a violation of GEM's idea of (well, kind of)
> 'object oriented-ness'. It's, for instance, not possible to open files
> of a given type with some (application-) program if the resource file
> for that program happens to reside in any other but the current
> directory.
 
That's not entirely true.  Your .RSC files don't _have_ to be in the
current directory.  If you set your PATH environment variable to:

	PATH=c:\bin

GEM will look in c:\bin for the application and any .RSC files.  

The problems are:

1.  GEM doesn't provide any way of setting the environment variables.

    I use GEMBOOT, which provides a means of setting the environment
    variables _before_ the desktop comes up.

2.  The application may look for other required data files in the
    current directory.

    I consider this bad design on the part of the application.  Does
    anyone out there have a work around (not including copying the
    application's data files into all directories :-) ?

3.  The path seperator character expected by GEM is ';' (semi-colon).

    I use MWC's msh, Beckmeyer's Micro C-shell, and Gulam.  They all
    use ',' (comma) as a seperator.  This caused two problems that
    confused me for quite a while:

    1) GEM applications invoked from a shell didn't always work.

    The problem was that GEM didn't grok the PATH set up by the shell,
    and the application couldn't find it's .RSC and other files.

    2) The shells couldn't handle the PATH set up for GEM.

    I used to set up PATH as: 

	PATH=C:\APP;C:\BIN;C:\ETC;C:\

    which worked fine from the desktop, and GEM could find
    application's and their .RSC files in any of the listed
    directories.

    The problem was that seemed to confuse MWC's msh.  It couldn't
    seem to find it's startup file "profile" no matter _where_ I put
    it.  The symptom was some obscure message (like "End of file in '"), 
    which didn't help in finding the problem.

There is an AES function: shel_find() that will search through the
directories listed in PATH for the given file name, and returns the
full path for the file if found.

Now, if shel_find() recognized ',' as a delimiter, or if all the
shells used ';', all this would work together rather nicely...

(BTW, if I got any of the above wrong, I'd love to be corrected :-)

--
Preston L. Bannister
USENET	   :	ucbvax!trwrb!felix!preston
BIX	   :	plb
CompuServe :	71350,3505
GEnie      :	p.bannister