[Gretl-devel] 'include' w/o 'open' -- new behavior

[Allin Cottrell]

On Sat, 15 Dec 2007, Sven Schreiber wrote:

> Below is an attempt to summarize the situation...
> 
> The four rules of path references in scripts:
> 
> 1) plain name or relative path -> location is relative to either 
> the userdir or the cwd depending on the preference settings for 
> opening/saving files

Sort of. 

* For the file read commands (append/open, run/include) we search 
as described in the manual, with the addition that if the filename 
is of the form "./foo" (or similar; I'll call these dotnames) we 
start by checking the shelldir.

* For the file write commands (eqnprint -f, tabprint -f, outfile, 
store) we use the userdir unless we're given a dotname, in which 
case we use the shelldir.

> 2) absolute path -> is honored, may include runtime stuff like 
> @userdir or strings from getenv("HOME")

Yes.

> 3) ./ -> depends on the shelldir setting

Yes.  And the shelldir is initialized to the CWD on program 
start-up (though of course its settable thereafter).  One other 
thing: on read, if "./" doesn't find the file in shelldir, we also 
try the actual CWD (which may not equal shelldir, for example if a 
shell command involves a "cd").

> 4) execution location of shell commands ('!') also depend on 
> shelldir setting

Yes.

> And last but not least:  the cwd seems to be very fragile, 
> especially on windows

Could you give an example of what you mean by fragility?

Further question from Sven:

> have I understood correctly that it is not possible to reference 
> from a script another file which is in the same directory? (of 
> course unless that directory is also the userdir or similar, and 
> unless the directory's name is hardcoded into the script) 

Do you mean, that if a script references another file given as a 
plain (non-dot) relative path, gretl will look for the latter in 
the same place the script was found?  If so, this is the case for 
open/append and run/include.  For example, if I do

gretlcli -b /some/odd/place/foo.inp

and foo.inp says "open baz.gdt", then we try looking for baz.gdt 
in /some/odd/place.  There's an internal variable "currdir" which 
is set/reset each time a script is opened, and this directory is 
prepended to the search path.

Allin.