Hi Christopher, Andreas, > > I could install all my supporting files in @lib/ in the picolisp > > installation directory. > That is one way to do it. Alex usually does it this way afaik.
I would not store application-specific stuff under @lib/, but it is true that on production servers I usually have the current working directory at @/ (for the local installation. The global installation at /usr/bin/ etc. is left as it is). > You could also create your own custom directory within the picolisp directory > and then refer to it with "@myDirectory/my-lib.l". Yes. > The argument(s) to (load) don't have to start with "@". > So you could also load from absolute paths, e.g.: > - (load "/home/user/programname/foo.l")) > - (load (pack *Prefix "/share/programname/foo.l")) > > The current directory is not changed during executing of (load), so if the > loaded files refer to additional files, those paths should also be absolute. The same (*Prefix) would hold when all paths were relative. > There are also: > - (cd "/home/user/programname") -> change the current directory permanently > - or (chdir) to change the directory just for some 'prgs, e.g. (chdir > "/home/user/programname") (load "foo.l")) > > In my installations I always execute the program in it's own directory or > switch to that directy with (cd), anD I load all includes from relative paths. I second that. Usually you will have to keep in mind not only the 'load'ed sources, but also data files like config stuff and the database and blob directories, so I find changing the working (sic) directory the best way. ♪♫ Alex -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
