Re: [Gretl-devel] "start gretlcli.exe" vs. simple "gretlcli.exe" (on Windows)
On Sun, 15 Jan 2017, Sven Schreiber wrote:
Am 15.01.2017 um 19:10 schrieb Allin Cottrell:
> 2) Per-process output files: I think that for most users most of the
> time it would be more user-friendly to gather the content of these files
> and consolidate the output, so that's what I've done. I guess one could
> have an option switch in this regard.
I have also been thinking whether writing the output files is
actually more of a debugging option, pushing for / assuming that
everything valuable should be put into the bundles.
Perhaps, but I could see a case for printing stuff, depending on
the character of the user's code.
> I haven't done anything about this in my current variant, but
if it were
> my package I'd probably want to give the option of supplying the
> user-code via the name of a script file rather than a hansl string.
That was actually the idea for normal use cases, but I thought the contents
string could always be produced on the fly by "readfile(<pathstring>)".
Yes, that would work.
> Last small point: my variant cleans up its temporary files, if we
don't
> want to preserve tham for debugging purposes.
I'm still undecided whether it should be a requirement that the
current gretl instance has shell commands enabled, now that mpi
and not the shell is used. Is there actually a way to check
programmatically that gretl preference setting?
Not directly, but it can be done:
<hansl>
function scalar shell_ok (void)
outfile tmpbuf --buffer
set # read the "set" variables
outfile --close
string s = strstr(tmpbuf, "shell_ok") + 10
return atof(s)
end function
</hansl>
Allin