Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!ukma!gatech!hao!ames!amdahl!oliveb!felix!preston From: preston@felix.UUCP (Preston Bannister) Newsgroups: comp.sys.atari.st Subject: Re: New Mark Williams C Message-ID: <22672@felix.UUCP> Date: 22 Feb 88 08:39:14 GMT References: <346@coma.UUCP> Sender: daemon@felix.UUCP Lines: 72 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