Menu

#5 Have CLIPSPATH to locate input files

CLIPS
open
nobody
API (3)
5
2012-11-23
2010-06-18
No

I came up with a new idea of a small enhancement - right now all
load/save/... operations require a file name which must be accessible
exactly as specified. This makes using Clips embedded within a program
hard, which may be relocatable and where I don't know where is is
started from.
If my Clips code says somewhere (load bla.clp) then bla.clp must exist
in the same directory as the current dir of the executable - which may
be correct or maybe not.
Alternatively, I can specify (load /some/path/to/my/clp/files/bla.clp)
but I don't want to hardcode this in my CLP main file.

Solution would be to have something like a search path - there could
be an env var CLIPSPATH which accepts a PATH in UX or Windows
style like /a/b/c:/d/e/f:/some/path/to/my/clp/files which will be used
in all load/save/... functions.
This way my executable can set this path appropriately (depending on
where it is installed) and in the CLP code I still can say (load
bla.clp) which then looks through the SearchPath if there is one.
Seems fairls easy to do, no side-effects, existing progs should not be
affected.

Discussion

  • thomas gentsch

    thomas gentsch - 2010-06-18

    sysdep.c patch

     
  • thomas gentsch

    thomas gentsch - 2010-06-18
     
  • thomas gentsch

    thomas gentsch - 2010-06-18

    Generally works with g++/Linux and mingw or MSVC on Windows.
    Slightly modified the behavior in a way, that this only applies to files which are to be opened for reading as I probably don't want to create/write files at a location which may be variable.

    Meanwhile I still have the code in a locally modified version but don't use it anymore because of a different approach of loading CLP files. However, it still might be interesting to other people ...

     
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.