#2662 windows: gnuplot keeps script file open after loading it

[Daniel Dan K.]

Dear all,

gnuplot seems to keep script files open after loading them. How do you notice? For example, it's impossible to rename a script file after is has been loaded by gnuplot until gnuplot is closed.

How to reproduce:
1. on Windows, open wgnuplot.exe or gnuplot.exe
2. load a script using "load" command
3. try to rename the script using Windows explorer.

You will see a message window that states "The action can't be completed" because "File In Use". See attached screenshot.

Thanks.
Daniel

PS: I don't know how to insert an image inline, uploaded as an attachment instead
PPS: Running gp 5.4pl6 from gp546-win64-mingw.exe

[Ethan Merritt]

For what it's worth - gnuplot definitely does issue fclose() on the file descriptor for the loaded script file. I do not know why that isn't sufficient for Windows,

[Daniel Dan K.]

Dear Ethan,

I figured that this issue is triggered by using the terminal "qt".
So this is the minimal code required to observe this behaviour:

set term qt
plot [-1:1] sin(x)/x

I do not observe this behaviour when using term wxt.

[Ethan Merritt]

Is the set term qt command inside the script, or do you first set the terminal and then load the script?

[Daniel Dan K.]

The set term qt command is inside the script. The script consists of the lines I quoted above.

[Ethan Merritt]

Aha. That may explain it. With the caveat that I have never worked on WIndows and have only a vague idea how its file-handling works, here is what I think is happening and possible work-arounds.

Several gnuplot terminals, including qt, start up a separate process to draw a plot window and respond to mousing events in that window. If the set term qt command that caused the separate process to be started is inside a script, then that script is the input stream for the new process. In principle the new process could continue to read from that script file, although in the case of gnuplot's qt window process that doesn't happen. I am guessing that in this case Windows considers the script file to be still in use (by the qt window process) even though the main gnuplot process has finished with it. I predict that if you close the qt window the file will be released, even if gnuplot is still running.

Work-around #1 - I am reasonably sure that moving the set term qt command outside the script would avoid this.

Work-around #2 - To avoid having to modify your script, it might be sufficient to open a qt window, thus starting the separate process, before loading the script. I.e. the sequence of commands would be something like set term qt; clear; load "myscript". The clear is just to force the qt process to actually do something. Although I don't know exactly how this works on Windows, I think that when the second set term qt is seen inside the script it will connect to the existing window rather than starting a new process.

Fix? - I don't know what commands are possible in Windows, but perhaps there is a way to have the new qt process "let go" of open file descriptors. For that matter perhaps there is a way to tell Windows that shared access to the script file is OK. But I will have to leave those possible solutions to someone working on Windows.