Re: [Gretl-devel] "start gretlcli.exe" vs. simple "gretlcli.exe" (on Windows)
Am 10.01.2017 um 12:17 schrieb Riccardo (Jack) Lucchetti:
On Tue, 10 Jan 2017, Sven Schreiber wrote:
> start gretlcli.exe -b hansltemp.inp > testy.out
>
> The testy.out file gets overwritten as expected, but it is empty (0
> bytes). I know this might be a Windows issue instead of a gretl issue,
> but perhaps somebody has an idea about what's going on nevertheless.
Hm. Even if it turns out to be an OS issue, it'd be good to delimit it
properly so we know what to say to users. To be on the safe side, I've
found myself relying more and more on the outfile command rather than
the OS piping features.
OK, I seem to have solved this issue by using "! cmd /C gretlcli.exe"
instead of "! start gretlcli.exe". At least my usage is producing the
desired results.
Speaking of my usage, I'm attaching the interim result of all this
tinkering with subprocesses. Hint: It's a gretl function for
embarassingly simple parallel processing that wraps all this shell
handling, and is based on arrays of bundles. There's a fairly extensive
explanatory text at the top, and a dummy example at the bottom.
> (I also have a totally different issue with a silently failing
bread()
> function in a loop which somehow ignores part of the bundle contents,
> but I leave that for later...)
That could be due to the bread() function being invoked when the buffer
is not yet committed to disk. We fixed that a few months ago in a way
that I thoughtwas definitive, but it obviously isn't :) If you could
provide a real test case, that would be very helpful.
The problem doesn't appear anymore, so I'm inclined to think it was
triggered by fallout from the "! start gretlcli.exe" invocation.
(Optimism is the friend of the lazy...)
thanks,
sven
Attachments:
- parallel_embarassing.inp (application/x-gretlscript — 5.8 KB)