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".
> 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.