On Sat, 23 Feb 2019, Allin Cottrell wrote:
On Sat, 23 Feb 2019, Sven Schreiber wrote:
> Am 22.02.2019 um 22:24 schrieb Allin Cottrell:
>> Hmm, it's more complicated than I thought. In the Linux console (X not
>> You'll see that I'm trying to emulate the SVAR situation by
>> putting the (unrealizable) gnuplot call inside a loop, in a
>> function called by a function. Yet here, too, the inevitable
>> failure of the plot call lands me back at the gretlcli
>> interactive prompt -- I'm not dumped out to the shell.
>> So more investigation needed!
> Well, so maybe this is specific to the Windows Subsystem for
> Linux after all. Or were you able to replicate the failure with
> the awm.inp script?
I should have said: yes, I can replicate the awm.inp failure in
the native Linux console. But I'm having difficulty determining
what the "active ingredient" is.
Aha, finally found the source of the problem, which actually has
nothing to do with gnuplot or 3rd party programs in general.
Using "run" interactively in gretlcli has apparently been little
explored. The intent was that (a) a script executed in this mode
should be stopped at the first error (unless trapped by "catch") but
(b) even if the script errors out the user should be returned to the
gretlcli prompt (i.e. gretlcli itself should not be aborted, just as
the gretl GUI doesn't get aborted on an error in a script).
However there were two things wrong -- in "opposite directions", so
1) If an error occurred within a loop at the top level of a script
called via "run", this caused gretlcli to exit. This was the case
with the SVAR example script awm.inp, when called in an environment
in which a plot could not be displayed.
2) Otherwise, even when "catch" was not deployed, an error in a
script called by "run" would not necessarily terminate the script's
Both of these points are now fixed in git; snapshots to follow.