I have a script and a workfile in the same directory (and that directory is not the CWD or dotdir or anything). The script starts with the open command: open ea16_96m1_sven18feb10.gdt --quiet and after starting gretl everything works fine. However, when I modify the script a little bit, save it, and then execute it again, I get an error: ? open ea16_96m1_sven18feb10.gdt --quiet Fehler bei Skriptausführung: Stopp Restarting gretl cures the (apparently reproducible) issue.

On Sat, 13 Mar 2010, Sven Schreiber wrote: > Sven Schreiber schrieb: >> I have a script and a workfile in the same directory (and that directory >> is not the CWD or dotdir or anything). The script starts with the open >> command: >> >> open ea16_96m1_sven18feb10.gdt --quiet >> >> and after starting gretl everything works fine. >> However, when I modify the script a little bit, save it, and then >> execute it again, I get an error: >> >> ? open ea16_96m1_sven18feb10.gdt --quiet >> >> Fehler bei Skriptausführung: Stopp >> >> Restarting gretl cures the (apparently reproducible) issue. > actually it seems that it's enough to reload (close/open) the script > file to work around this issue I'm not convinced this is a bug. If you want to ensure that files in a particular (ad hoc) directory are found, the best way is to make that your PWD and choose the option to make your gretl working directory respect the PWD on start-up.

Allin Cottrell schrieb: > On Sat, 13 Mar 2010, Sven Schreiber wrote: > >> Sven Schreiber schrieb: >>> I have a script and a workfile in the same directory (and that directory >>> is not the CWD or dotdir or anything). The script starts with the open >>> command: >>> >>> open ea16_96m1_sven18feb10.gdt --quiet >>> >>> and after starting gretl everything works fine. >>> However, when I modify the script a little bit, save it, and then >>> execute it again, I get an error: >>> >>> ? open ea16_96m1_sven18feb10.gdt --quiet >>> >>> Fehler bei Skriptausführung: Stopp >>> >>> Restarting gretl cures the (apparently reproducible) issue. >> actually it seems that it's enough to reload (close/open) the script >> file to work around this issue > > I'm not convinced this is a bug. If you want to ensure that files > in a particular (ad hoc) directory are found, the best way is to > make that your PWD and choose the option to make your gretl > working directory respect the PWD on start-up. > I was doubting it myself, but then I found this in the command ref: "When a command script contains an instruction to open a data file, the search order for the data file is as stated above, except that the directory containing the script is also searched, immediately after trying to find the data file as is."

Allin Cottrell schrieb: > I've just experimented and I can't reproduce the problem you > describe. That is: > > * In gretl GUI, open script from ad hoc location (not working > directory, not shell PWD) via File menu. This script starts with > a command to open a datafile with no explicit path given, and the > datafile in question is in the same ad hoc location. > > * Run script; datafile is found OK as advertised. > > * Make changes to script and save it. Re-run script. Datafile is > still found. > > I don't doubt that you're seeing what you're seeing, but could you > give a little more detail? What does the script do, for instance? > It does a lot ;-) I will try to narrow it down tomorrow.

Sven Schreiber schrieb: > Allin Cottrell schrieb: > >> I've just experimented and I can't reproduce the problem you >> describe. That is: >> >> * In gretl GUI, open script from ad hoc location (not working >> directory, not shell PWD) via File menu. This script starts with >> a command to open a datafile with no explicit path given, and the >> datafile in question is in the same ad hoc location. >> >> * Run script; datafile is found OK as advertised. >> >> * Make changes to script and save it. Re-run script. Datafile is >> still found. >> >> I don't doubt that you're seeing what you're seeing, but could you >> give a little more detail? What does the script do, for instance? Ok, it seems pretty clear now: The essential structure of the script is: open file_in_same_directory.gdt include ../script_in_upperlevel_dir.inp And the "jump" to ../ seems to confuse the path-finding apparatus.

Allin Cottrell schrieb: > On Sun, 14 Mar 2010, Sven Schreiber wrote: > >> The essential structure of the script is: >> >> open file_in_same_directory.gdt >> include ../script_in_upperlevel_dir.inp >> >> And the "jump" to ../ seems to confuse the path-finding apparatus. > It's rather that doing "include" has switched the "current" path > to the one where the second .inp file was found. Bug or feature? > For the present I've modified the behavior so that "include" > doesn't alter the "current" path. > Thanks! A follow-up question: Your explanation sounds as if the current path is "fixed" at where the top-level script resides. For the sake of my question consider the following arrangement: <some_dir>/toplevelscript.inp <some_dir>/nextlevel/secondscript.inp <some_dir>/nextlevel/thirdscript.inp And 'toplevelscript.inp' contains: include nextlevel/secondscript.inp while 'secondscript.inp' contains: include thirdscript.inp Would that situation fail? (Because the 'current path' is fixed at <some_dir> and thus thirdscript.inp isn't found?) The general background is simply that I'm struggling a little on how to organize my gretl scripts in order to achieve these two independent goals: 1) Allow code-reuse and avoid version-change chaos, and thus do not store included backend scripts with self-written functions in the several different places where the calling scripts reside. Instead have a single location for them. 2) To be able to do easy backup and file-synchronization across different machines, do not use the default gretl directories for functions etc. Instead use my own directory hierarchy in my home dir. I know how to achieve each of these objectives in isolation, but the combination seems a bit difficult without using nested relative paths.