- status: open --> pending-fixed
- Group: -->
- Priority: -->
Hi. I'm seeing an issue about half the time when I run gnuplot with a very specific set of conditions (these just happen to be conditions that are VERY common in my workflows). To reproduce you must be using the x11 terminal ("set terminal x11" in ~/.gnuplot is sufficient). And you must be x-forwarding (the slowness in the X communication is what tickles the bug probably). And you must feed gnuplot from a pipe, not from a file. Recipe:
ssh somebox
echo -n "plot x\npause mouse close\n" | gnuplot
I would expect a plot to pop up, and I would expect gnuplot to exit when I close the window. This happens some of the time. It happens ALL the time without X-forwarding or with a different terminal or if we put that script into a file and give gnuplot the FILE instead of a pipe. Failure looks like this:
gnuplot> ause mouse close
^
line 0: invalid command
I.e. something stole the "p" from "pause mouse close", and gnuplot doesn't understand the command without the "p".
I just spent a bit of time debugging, and I know what code path makes things break. This is the thing that reads off the "p":
https://github.com/gnuplot/gnuplot/blob/fb057592067197fc91fa8de5b519d22bdf3f3b1c/term/x11.trm#L1444
It looks like stdin is multiplexed for several purposes, and here something gets out of sync, and the two purposes clash. I don't have an understanding of what this is doing currently. I did do some reverting to see if this was a recent regression, and it looks like the issue is old, and may go back to when that X11_waitforinput() was added in <=2003. Eventually I couldn't build the code because the new autoconf wouldn't accept the old configure.ac
Does anybody understand what we're doing here?
Thanks!