Re: again: x11 is eating one character from stdin pipe

[Daniel J S. <dan...@ie...>]

I haven't been following too closely, but here's an observation
that may or may not be related.  I've notice for a while that if
one uses the mouse to copy text to Gnuplot's command line
(i.e., the "clipboard" method, or whatever) that whenever there
is a "pause -1", the first character after the pause is always
deleted.  That is, it will interpret all lines up to "pause -1"
correctly, then wait for the keyboard to hit, then the first character
after the keyboard hit is lost.  If it is a non-whitespace character,
Gnuplot will have a syntax error.

Dan



Ethan Merritt wrote:

>On Tuesday 21 October 2003 02:36, Petr Mikulik wrote:
>  
>
>>Ethan Merritt wrote>
>>    
>>
>>>Commenting out this one setvbuf() line solves 99% of the
>>>problem in my tests using the awk script below.
>>>
>>>With the setvbuf() in place, running the awk script causes the
>>>first 120+ plot commands to be lost in transit!!!!!!
>>>
>>>Without the setvbuf() command, only a single character is
>>>dropped - the first one following the first plot command.
>>>      
>>>
>>I've tried it with Octave, but there is no change with or without
>>setvbuf. Gnuplot mostly looses the first character.
>>    
>>
>
>Last night I built Octave 2.1.50 so that I could test this
>myself. What I found is that the Octave problem and the awk
>problem are not the same.
>
>The Octave problem can, I believe, be solved with the first
>patch attached below (ipc_lock.patch).  This one causes
>X11_waitforinput() to refuse to read any more characters
>using getc(stdin) while it is waiting for a response from the
>mousing pipe. 
>
>This still leaves awk losing many lines of input, which is
>fixed only if I also remove the call to setvbuf() as in the
>second patch below (setvbuf.patch).
>
>Applying these two patches makes both the awk and octave
>test scripts run on my usual desktop machine under linux.  
>
>I've tested both with gnu libreadline and with the builtin
>readline. But I have not yet tested on other machines, and
>I would not like to commit either patch to CVS without more
>extensive testing.  
>
>In particular I am concerned that if the response from the
>mouse pipe is lost altogether, then the first patch will cause
>gnuplot will hang.  I need to add some sort of timeout or
>upper limit of attempts to read from the mouse pipe.
>
>  
>