Am 31.12.2007 17:40, Allin Cottrell schrieb:
...
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.)
sounds good
* 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.
yes in principle; however, if ./-names don't carry any special meaning
anymore under the new scheme, why not keep the old behavior for
backwards compatibility, at least for a while?
"@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.
I agree. BTW, is/should workdir be user-adjustable in a script?
Happy new year!
Sven