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. (It
seems that the built-in cleverness of Python's path searching spared me
any problems related to this.)
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.)
(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 ./? If
the user has a certain directory in mind, she can always provide the
(absolute or relative) path as part of the store/outfile command.
(Repeating also my second-best suggestion: make ./ the dir of the
containing script.)
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.)
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()"
And wrapping with double quotes is even more problematic, because they
are needed for so many other things (paths with spaces, for example).
Thus of course the following also doesn't work:
? ! python -c "f=open('"(a)userdir"\test.txt', 'w');
f.close()"
That's why I find the "set shelldir" feature so interesting, because it
seems like the best way to achieve these things.
I guess I can see a possible argument for using shelldir when
faced with a plain filename (case b), if shelldir has been
explicitly set by the user. But I'm not sure if that is more or
less confusing than always defaulting to @userdir.
No I still think is to leave shelldir for "!" only, and for (b) see my
comment above.
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.
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.
3) If a script author wants to enforce the CWD, use "./"
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?
oK, so much for that...
-sven