Windows ginput function [Was: fopen doesn't return when opening a fifo!!]

[John W. Eaton]

On  2-Apr-2008, David Bateman wrote:

| It is the __gnuplot_ginput__.m function that sends the command to print
| to  gnuplot, so we are in full control of the output. To try and address
| some of these issues, I added a tag in front of the expected output (ie
| "OCTAVE:") and so we can reject the rest.

OK, so there could be other output mixed in?  What other things does
gnuplot write to stdout?

| I see the output stream from
| gnuplot opened with popen2 to be blocking reads just around the read
| statement to prevent the need to a while loop around the read, though if
| you feel the while loop is better to allow ctrl-c to work then that's
| easy to implement as well. I should probably also have a while loop
| looking for the expected "OCTAVE:" tag as well, to prevent rubbish that
| might be printed by gnuplot affecting the use of ginput.

I think it would be best if we can have a way for interrupts to work
here, otherwise it seems we would be stuck if gnuplot fails to respond.
| 
| > If it works, then why not use popen2 unconditionally?
|
| The read of the fifo blocks, but doesn't use resources and is
| interruptible with ctrl-c, whereas a blocking read on the pipe doesn't
| seem to be without quitting Octave. Also as the fifo is only for the
| mouse data, there can be no confusing with any other output from
| gnuplot. I think the mkfifo method is more secure for this reason.

OK.

| In all cases the pipe to gnuplot is opened with popen2 in my proposed patch.

What is the new argument to open_gnuplot_stream for?  In the patch you
sent, one possibility was to open the pipe to gnuplot with popen.

jwe