Description of problem: If gnuplot is run from the command line with the command "gnuplot <filename>" where <filename> contains a gnuplot script, the plot flashes briefly on the screen, then the user is returned to the command prompt. If, instead, the user runs "gnuplot" with no filename, gnuplot starts and it is possible to create a plot with a simple command like "plot sin(x)" but if the text of the script is input it just sits there. Sample demo scripts are available at http://gnuplot.sourceforge.net/demo/ I will attach one to this bug. When I tested gnuplot for Mageia 7 for Bug 28463, it worked fine with these demos. Version-Release number of selected component (if applicable): Version: 5.4.1-3.mga8 How reproducible: Every time Steps to Reproduce: 1. Install gnuplot, either arch. 2. run with the demoscript with the command "gnuplot plotdemo.txt"
Created attachment 13051 [details] gnuplot demo script
Shouldn't one use switch -p with scripts? OPTIONS -p, --persist lets plot windows survive after main gnuplot program exits.
There's also a configuration option in GUI to not quit until all windows are closed.
Jani is right on both counts! From the man page: "If file names are given on the command line, gnuplot loads and executes each file in the order specified, and exits after the last file is pro‐ cessed." Trying this from the command line: 1. without flag or frigging the config: $ gnuplot Desktop/plotdemo.txt Briefly shows the plot, then exits. As per TJ. 2. With -p option, no config frigging: $ gnuplot -p Desktop/plotdemo.txt displays the graph, whose window stays. 3. With the config frigged: "Don't quit until all windows are closed (persist)" ticked: $ gnuplot Desktop/plotdemo.txt Graph window stays up.
CC: (none) => lewyssmithStatus: NEW => RESOLVEDResolution: (none) => INVALIDSource RPM: (none) => gnuplot-5.4.1-3.mga8.src.rpm
OK, I see that now. User error, coming from lack of experience. I've only used gnuplot a couple of times to test for QA. I ran it this time because it shares a dependence with guayadeque (bug 29742), and I was investigating to see if that dependency might be crashing something else, too. The default behavior is different from what I saw when I tested for Mageia 7. Then, persistence was the default, or I managed to change the default without knowing it. That's why I brought the whole thing up - it just didn't act quite the same. But, it seems to be acting as designed. Closing this bug as invalid.
Mid-air collision, Lewis! You beat me to it!