[Gretl-devel] dotdir (was Belated response to Sven on function packages)

On Tue, 1 May 2007, Sven Schreiber wrote: OK, I've now done some more experimentation. On Linux I didn't at first notice the effect you mentioned, though I now see it's there. The basic point is this: at present the "./" notation does literally what it says; that is, it references the current working directory (CWD). This starts off as whatever directory (the OS deems) gretl was started from, but the CWD is changed by various gretl file operations -- apparently, more so on Windows than on Linux, probably due to how the Windows file selector works. As you say, this means that the effect of using "./" in filenames in a script (or in the console) is unpredictable. I can think of at least 3 contexts where "./" might be used: (1) for the filename given to "store" (2) for the filename given out "outfile" (3) in a shell command line ("!" or "launch") The effect in case (3) can be controlled by set shelldir /some/path but at present the user has no real control in cases (1) and (2). It would not be difficult to plug "store" and "outfile" into the shelldir mechanism, so that for example set shelldir /some/path outfile "./some.txt" --write would open /some/path/some.txt. Aother possibility (which could be combined with the above) would be to record the CWD at startup and write that in as the default value for shelldir. (Right now it's an empty string until set by the user.) That still leaves a few tricky issues. * In the console/script context, should we pay any attention to the GUI configuration choice of using the @userdir or the CWD as the default for saving files? In the GUI context, this determines the location in the filesystem at which the File, Save dialog points initially. This could be read over into the console/script situation, or not. * Related to the above, should we make a distinction between the filenames "foo" and "./foo" for opening a file for writing in the console/script setting? The shell itself makes no such distinction (well, it does in the case of calling executables, but that's not what we're talking about here). * As for setting shelldir as CWD on startup, what about (most?) GUI users who don't even know what that directory is? From their point of view we'd be better to let shelldir default to @userdir -- or should we just assume that such users will never have occasion to write such files anyway, so we can ignore them? One point seems clear: packaged functions should never use "./" filenames (or relative paths at all) unless they're very sure what's implied (i.e. unless they have set shelldir or the equivalent). Packages should not assume that the startup CWD means anything, or is writable by the user. Thoughts? Allin