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.

♪♫ Alex

UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to