Re: [Gretl-devel] directory structure in CVS

On Sun, 30 Dec 2007, Sven Schreiber wrote: I _think_ I'm now getting clearer on this. I've added "/File/Working directory" with two permanent options plus a "recently visited" list. The two options are (a) GUI selection of working directory (with a mouseover tooltip showing the current path) and (b) "Use startup directory" (again, with a tooltip exposing what this is). Selection from this menu directly changes the working directory. I've also (c) got a checkbox under Preferences/General, "Set working directory from shell". This does not change the working directory right away (and it notifies the user of this via a popup when the box is checked or unchecked). Rather, its function is to establish or remove the _policy_ of automatically setting the working directory to the shell CWD on gretl startup. It's perhaps unlikely that Windows or OS X users will have cause to use (b) or (c), but they might. A Windows user might find it helpful to define gretl startup icons with specific starting directories in their "Properties". As for OS X, the gretl startup script has to "cd" to the "bin" directory under Gretl.app before actually starting the gretl GUI, which potentially screws things up, but I'm now recording the user's real CWD prior to doing that and exporting it as an environment variable, which gretl then picks up. So it should be possible to support the "use startup directory" option on OS X too (not tested yet). Now for another thing: if we've finally got the working directory business right, it's time to revisit "shelldir" and the special meaning given to "./XXX" filenames in some contexts. Recall that "shelldir" is the directory in which "! XXX" shell commands are run. My proposal is * Always default shelldir to workdir. (This will equal the startup CWD if and only if that's what the user has asked for.) * Don't try to do anything fancy with "./XXX" filenames (in store, outfile, eqnprint, tabprint): if the given path is not absolute, always write such files to workdir. "@workdir" is now available as a built-in string. Suppose a user-function calls "outfile" then wants to do some shell processing on the output. That shouldn't be a problem. If you know that "outfile foo --write" always creates "@workdir/foo" then you know how to access foo for reading. "set shelldir" may still be useful for some purposes: we may want to shift the location for shell execution temporarily to, say, the tramo directory, as in some of Ignacio's functions. So although I think we should default shelldir to workdir, I don't think we should collapse the two. Allin.