Could someone please enlighten me on what defines the expected
behavior in this case? To me it does not seem like a bug at all.
The behavior is not specific to the wxt terminal or to a remote
session. It is visible already on a local session. In fact, you
don't even need to kill the x11 window:
% cat hang.bug
plot x
pause -1
print "back from pause"
%gnuplot hang.bug
==> kill x-window externally if you like (doesn't matter)
==> do NOT hit <cr> in the original terminal session
Now from another terminal inspect the gnuplot process, which is
still waiting for input from the original:
#0 0xffffe424 in __kernel_vsyscall ()
#1 0xb6ad7201 in select () from /lib/i686/libc.so.6
#2 0x0812ac4d in wxt_waitforinput () at wxterminal/wxt_gui.cpp:3098
#3 0x08062570 in pause_command () at command.c:1202
#4 0x080635b9 in command () at command.c:596
#5 do_line () at command.c:378
#6 0x0809ebd6 in load_file (fp=0x931b4e0, name=0x931b6f8 "hang.bug",
can_do_args=
false) at misc.c:284
#7 0x080a6aaa in main (argc=2, argv=0xbfca6e68) at plot.c:619
The thing is, the "pause -1" command is doing exactly what it is supposed to.
The process is waiting to receive a <cr> from the terminal session before
continuing. If you now break or otherwise lose your connection to that
terminal session, then gnuplot is left waiting for a <cr> that will never
come.
But is this a bug in gnuplot?
Why is it different from any other hung terminal session?
You get the same behaviour from any process that is backgrounded
while waiting for terminal input. Right?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
