On Thu, 3 May 2007, Sven Schreiber wrote:
Allin Cottrell schrieb:
> 1. When gretl starts, we record the initial CWD and set shelldir
> to this value.
I actually thought this was already the case, so I'm all for it.
Yes, it makes a lot of sense and I should have thought of it
before.
> 2. When we come across a filename in a store or outfile (or
> similar gretl) command we do the following:
>
> (a) If it's an absolute path, respect it (of course).
Yes.
> (b) If it's a plain filename with no explicit path element,
> we take it that @userdir is implied.
No I think gretl should rather respect the user preference setting
(userdir or CWD) in this case. (Or else get rid of this preference
option in gretl and leave that stuff to the desktop environment.)
OK, I can go with that.
> (c) If it's a "./" filename we use shelldir.
> (d) Shelldir can be changed by the user via the set command,
> and this will be respected in context (c).
For (c) I repeat that I would prefer to leave "./" untouched
after startup. What's the advantage for a user of being able to
change ./?
Well, basically the same as being able to do "cd" in the shell
itself. You can then do things without having to type (possibly
long and possibly "have-to-be-wrapped-in-quotes" filenames).
Now ad (d): I like the idea very much that the context directory
for "!" can be set by a script. (I hope that's what it means.)
Yes, that's the primary intent behind "set shelldir".
> In the context of actual "!" shell calls, you can of
course do as
> you like, giving absolute paths, using the @userdir variable,
> setting shelldir, using "cd", or whatever. I don't propose trying
> to push output into @userdir in that context.
Now I don't quite understand this; I thought everything in a "!" line
after the ! would be just passed literally to the OS's shell. That means
I can type in absolute paths, or previously doing a "set shelldir" etc.,
but how can I use variables?
For example, this does not work (I never thought it would):
? ! python -c "f=open('(a)userdir\test.txt', 'w'); f.close()"
This must be one of those wretched backslash things; it works fine
on Linux
? ! touch @userdir/test.file
? ! touch '(a)userdir/test.file'
Both are OK. I'll try some testing on Windows.
So altogether my suggestions would imply:
1) If a script author wants to use the gretl user directory or some
relative path based on that (ignoring the user's preferences), she must
use the @userdir variable for store/outfile and shelldir.
Yes, fine.
2) If a script author wants to honor the user's preferences, she
must
simply use a relative path to end up either in the gretl user dir or in
the CWD.
Ditto.
3) If a script author wants to enforce the CWD, use "./"
Again, OK.
What's not possible by gretl's design is to use $HOME (or
whatever it's called), or did you already implement Jack's
getenv suggestion?
Not yet; maybe later today.
I think the only point on which we're not quite agreed is whether
it makes sense to have "set shelldir" work as a sort of "cd" which
affects the default path for outfile and so on. But I don't have
very strong feelings about that, and I can see that it might be
cleaner to let shelldir affect only shell commands.
Allin.