Re: [Gnuplot-info] Interrupt gnuplot when it's waiting for pipe input?

[Craig D. <def...@bo...>]

Hmmm,  it seems that the INT signal doesn't make gnuplot do what I want it to do for the pipe case.  In particular, if I'm sending binary data over a pipe and issue an INT, it doesn't make gnuplot start accepting new commands over the pipe.  As near as I can tell, gnuplot continues to read from the pipe regardless.

So INTing seems to work fine over a tty but not over a pipe control link.





On Feb 12, 2013, at 3:37 PM, Craig DeForest <def...@bo...> wrote:

>> 
>> I am dubious that you would see slow communications between your perl script and gnuplot just because DISPLAY is remote.  The actual x11 rendering is done by a separate process, gnuplot_X11, and no matter how slowly it may be progressing gnuplot itself should be able to accept new input on stdin. 
> 
> Sorry if I wasn't clear here -- the communication is still fast of course, but the render can take a long time if X11 communications is slow.  Gnuplot doesn't issue any indication of state until the whole process completes.  Same goes for wxt, of course.  
> 
> 
>> 
>>         - Slow rendering jobs can be interrupted by the user, and there's no documented way (that I've found) to let gnuplot know to stop what it's doing and give a prompt back.  
>> 
>> In "normal" (i.e. interactive) mode you can get a prompt back by hitting ^C
>> (INT signal).  You should be able to achieve the same by sending INT.  I've just tested that this works from the command line using "kill -INT"
>> 
>> That doesn't specifically address your question about binary data being sent on stdin.  I'm not certain what state you will be left in if there is a binary read pending when you send an INT signal.
>>  
>>                    Ethan
> 
> Thanks.  Early experiments with "kill -INT" hosed up the pipe, but I'll run another round and see what happens.
> 
>