I also tried with "pgnuplot", "pgnuplot --version" and "r" and "rt", all combinations... I tried to give the full paths just out of paranoia ;), but always it returns 6...
I also tried _get_doserrno: it's return value could be also useful, except that it returns 123 and I couldn't find its meaning... (_get_errno returns just 0) (By the way I tried them in separate programs, so rest assured that they do not mess with each others).
----- Original Message ----
From: Michael Goffioul <address@hidden>
To: N. B. <address@hidden>
Cc: address@hidden
Sent: Tuesday, December 18, 2007 1:31:40 AM
Subject: Re: problem with gnuplot and octave, 2.9.19, MSVC build on windows XP
On 12/17/07, N. B. <
address@hidden> wrote:
>
> when I type
> DISPLAY
> in the octave prompt, I see that it's *not* defined.
> gnuplot_binary returns
> pgnuplot
>
> Michael, I don't know if this is relevant, but on my system, I tried the
> _popen example on MSDN and no matter what I do, it fails: it returns a null
> FILE*. And popen calls _popen... On the other hand, popen2 does not fail (it
> doesn't work, but it
doesn't return a null pointer), and if I'm not
> mistaken, it takes a different route.
> On the MSDN, I tried the _pipe example which does a similar job by via
> _pipe, dup, dup2 (I don't recall if they have underscores) and spawnvp and
> that example works. Does this tell you anything?
Indeed, octave uses internally _popen. So if a simple example does not work
on your system, this might be the reason gnuplot backend is not working.
However, I don't have any idea why _popen would not work. Could you try
to look at GetLastError() returned values after _popen fails in your simple
example. This might give some hints about the reason of the failure.
Michael.