#2675 Multiplot not working when piped in from an external program

[Matthew Halverson]

I've noticed a regression when piping into gnuplot from an external program. The following Python program demonstrates this:

import subprocess

gp = subprocess.Popen([r'gnuplot','-persist'],shell=False,stdout=subprocess.PIPE,stdin=subprocess.PIPE,stderr=subprocess.PIPE)
gp.stdin.write(b'set term pdf; set output "test.pdf"\n')
gp.stdin.write(b'set multiplot layout 2,2 title "test"\n')
gp.stdin.write(b'plot sin(x)\n')
gp.stdin.write(b'plot cos(x)\n')
gp.stdin.write(b'unset multiplot\n')
gp.stdin.write(b'set output\n')
gp.stdin.write(b'quit\n')
gp.stdin.flush()

This should create a pdf (test.pdf) with a 2x2 grid of plots (only 2 used) with one showing the sin plot and one showing the cos plot.

Running with Python 3.11.1 and gnuplot 5.4 (patch level 5), this instead creates the 2 plots on separate pages (ignores multiplot). With gnuplot 5.2 (patch level 0), this works as expected.

I am not sure at which version this stopped working, but it does not seem to work with 5.4.5. Running a script with the same commands or typing into the gnuplot terminal works as expected. The problem only occurs when accessing gnuplot as a subprocess. Everything seems to work except the multiplot command.

Attached: The output from both versions of gnuplot tested, the python script to generate the output, and the script file to test (running the script file works - it is only when piped in from Python that it breaks).

Platform: Windows 10
Gnuplot archive used: gp545-win64-mingw

[Matthew Halverson]

Edited as the wrong python script was attached.

[Ethan Merritt]

I can't reproduce this under linux. For me the script works correctly with gnuplot versions 5.2.0, 5.4.5, and the about-to-be-released version 6.0. So maybe a Windows-only problem?

[Matthew Halverson]

It is possible that it is unique to Windows. I don't have any other OS available to test, but it did work correctly under the older version of gnuplot on my machine but does not run under the new version. If you can't reproduce under Linux, I would suspect that it is somewhere in the Windows specific code.

What seems odd is that moving that multiplot command to the previous line:

gp.stdin.write(b'set term pdf; set output "test.pdf"; set multiplot layout 2,2 title "test"\n')

works to trigger multiplot, but only shows one of the graphs (the last one, but in in position 1).

Currently, for my use-case with this, I am needing to generate an intermediate script and run gnuplot on that instead of piping directly into it.

Attached: Modified script and result

[Ethan Merritt]

It might help to know whether the problem exists in subsequent gnuplot versions. I see one commit for 5.4.6 that could possibly be relevant:

commit 780f8bd414e67c6a226efa7952e134d732feb283
Author: Takashi Yano <tyan0@users.sourceforge.net>
Date:   Tue Feb 15 22:44:15 2022 +0100

    windows console: buffered pipe input

    Use read() instead of fgetc() to improve read speed. Avoid mixed access to
    pipe by our pipe reading thread and C file functions to prevent race condition.

    Bug #2491

Bug 2491 has something to do with a race condition on multi-core machines running Windows. Beyond that I have no idea.

[Matthew Halverson]

It may be related to that commit. Looking at the bug notes, I tried to pipe the gnuplot script into gnuplot (removing Python from the equation), and got an error suggesting that the second line of the script is parsed funny.

It produced the error message t multiplot layout 2,2 title "test"; line 0: invalid command (see attached screenshot). I bet this is also why the Python script didn't work. Trying both Windows and Linux type EOL's did not change the behavior. It seems whatever is on this second line gets scrambled. Adding a blank second line fixes it.

Adding the line gp.stdin.write(b'\n\n') as the second write command in the Python script also works.

It seems it is related to input is parsed in the windows console.

I tested with 5.4.8 (the newest version with a Windows build available), and it does seem to be fixed in that version. This can be closed as it is fixed in a newer version.

Attached: gnuplot script which does not work when piped in, gnuplot script which does work when piped in, python script which does work

[Matthew Halverson]

Looking at the additional ways this was failing, this is almost certainly the same bug as 2491.