Re: [Gretl-devel] 'include' w/o 'open' -- new behavior
Am 22.12.2007 00:46, Sven Schreiber schrieb:
Am 21.12.2007 23:27, Allin Cottrell schrieb:
> On Sat, 15 Dec 2007, Sven Schreiber wrote:
> 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.
>
Hm, ok, though my question arises from experiences where I thought that
wouldn't work. I'll report it as a bug eventually when I come across
something reproducible and clearcut.
I think I was just facing such a behavior after installing 1.7.1 on win
xp (thanks for this nice Christmas present BTW!).
As always, I installed as admin, but run as normal user. Before doing
anything else at all with 1.7.1, I opened an existing script file in
S:\my\project\dir. This dir is not specified in the preferences. The
script opens a datafile with the command
open mydata
(relative path pointing to same dir, no file extension), but although it
worked five minutes ago with the previous snapshot that had been running
for some time already, it didn't with the freshly started 1.7.1.
However, after I manually opened the datafile and thereby implicitly
adjusted the current working dir (I presume), it works again (my
preferences are currently set to use the cwd, not the user dir, for
opening files).
So that's what I meant, if I understand correctly this would mean that
the "currdir" was not updated properly when that script was opened.
Thanks,
Sven