Re: [Gretl-devel] 'include' w/o 'open' -- new behavior
Am 14.12.2007 19:22, Sven Schreiber schrieb:
Am 14.12.2007 16:34, Allin Cottrell schrieb:
>
> Up till now, the "./" notation for filenames has always just used the
> actual current working directory, which is not necessarily the same
> as "shelldir": the latter was used strictly for shell commands, and
> gretl's "open", "include" and so on are not shell commands.
However,
> this does seem unintuitive so I'm modifying gretl's path searching:
> if shelldir is set, it will be checked first when gretl is asked to
> open a filename that starts with "./" or "../".
>
>
Ah yes I vaguely remember all those directory issues when I was
hacking around with py4gretl. I still find it confusing though; some
day when I find the time I'll try to write down some documentation and
possibly make suggestions for improvement...
Below is an attempt to summarize the situation (corrections are most
welcome), but first let me ask: 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)
That would be a bit unfortunate IMHO (but I hope there is a clever way
to achieve this that you will tell me...:-)
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
2) absolute path -> is honored, may include runtime stuff like @userdir
or strings from getenv("HOME")
3) ./ -> depends on the shelldir setting
4) execution location of shell commands ('!') also depend on shelldir
setting
What commands are affected: include/run -- store -- outfile --
open/append -- ! (shell) -- eqnprint/tabprint -f
And last but not least: the cwd seems to be very fragile, especially on
windows
Is all this correct?
thanks,
sven