Re: Persistent confusion about gnuplot -persist

[Jun T. <tak...@kb...>]

First of all, I personally feel the current behavior of --persist is just fine.
If an equivalent of [2] is implemented within gnuplot, what a user can do if
she/he wants to get the current behavior of [1]?

Anyway, I tested the following three commands with term=aqua/wxt/qt on my Mac
so that you can get an idea about the situation on Mac.

term=xxx	# aqua/wxt/qt
[0] gnuplot -e "set term $term; splot x*y*y"
[1] gnuplot -e "set term $term; splot x*y*y" --persist 
[2] gnuplot -e "set term $term; splot x*y*y; pause mouse close" &

(OS X 10.8.5/gnuplot-cvs/wxWidgets-svn/Qt5.3.2)

=====[[ aqua ]]=====
Aquaterm.app is an application independent of gnuplot and does not
support mouse feedback.

[0][1] The gnuplot quits immediately but the plot window survives.
The plot can't be changed by mouse (this is always the case with aqua)
but I can print or save the plot from the Aquaterm menu.

[2] The gnuplot process goes into the background, and suspended (stopped) by
'tty input'. It does not quit even when the plot window is closed.
(If I bring the gnuplot to the foreground then it quits.)
Since aqua does not support mouse, 'pause mouse close' is equivalent to
'pause -1' and gnuplot is waiting for a carriage return to be hit.

=====[[ wxt ]]=====`
On Mac OS X gnuplot handles wxt by itself (does not fork).

[0][1] A plot window opens but closes immediately, and the gnuplot quits.

[2] The plot window survives and I can rotate the plot by mouse.
But If I change the focus to the terminal window from which I started the
gnuplot and enter a next shell command (or just hit return), then the gnuplot
process (in the background) is stopped by "tty input"; I can't change the
focus back to the plot window (it does not respond). If I bring the gnuplot
to the foreground then it quits and the plot window is closed.
I haven't yet understood why this happens.

=====[[ qt ]]=====
[0] gnuplot quits and the plot window is closed immediately.
[1] gnuplot quits but the plot window (gnuplot_qt) survives;
the plot can't be rotated by mouse (of course).
[2] The plot window survives and the plot can be rotated by mouse.
If the plot window is closed then the gnuplot (in the backgrond) also quits.
Changing the focus from/to the plot window causes no problem.

To summarize, on Mac OS X, [2] works fine with qt but not with aqua/wxt
(at least currently).
But implementing [2] within gnulot may not be equivalent to putting gnuplot
into background by shell, and the 'tty input' problem would not happen
(or could be avoided).

NOTE:
I noticed the following two are equivalent:
gnuplot -e 'cmd1; cmd2'
gnuplot -e 'cmd1; cmd2; exit'

In plot.c (line 622) noinputfiles is set to FALSE if '-e cmds' is given;
the '-e cmds' is considered as a kind of "input file".
The man page of gnuplot is somewhat ambiguous about the behavior when
'-e cmds' is specified but no input file is given.

Jun