#1950 "popen failed" appears in system command on wgnuplot.exe

[Tatsuro MATSUOKA]

This reported in the gnuplot-info list.
http://gnuplot.10905.n7.nabble.com/How-to-ignore-quot-popen-failed-quot-td20802.html
If one execute below in the directory where no *.dat

gnuplot> flist=system("dir /B *.dat")
                  popen failed

This does not happens on gnuplot.exe and wgnuplot_pipes.exe.

Is this a bug of wgnuplot ? Is this a side effect of fake pipe?

[Tatsuro MATSUOKA]

At present working directory where test.txt exist but not no *.dat files.
For gnuplot.exe and wgnuplot_pipes.exe

gnuplot>  flist=system("dir /B *.txt")
gnuplot> pr flist                     
test.txt
gnuplot>  flist=system("dir /B *.dat")
gnuplot> pr flist                     

For wgnuplot.exe

gnuplot> flist=system("dir /B *.txt")
gnuplot> pr flist                    
test.txt
gnuplot> flist=system("dir /B *.dat")  
                  popen failed

gnuplot> pr flist                    
test.txt

[Tatsuro MATSUOKA]

On wgnuplot.exe, pipe emulation is used (fake_popen, fake_pclose).

In fakepoen system (_wsystem) function is used.
system function returns 1 when no matching file exists.
(Tested below code)

#include <stdio.h>
#include <stdlib.h>

void main(void)
{
    int ret_sys;
    ret_sys=system("dir /B *.txt");
    printf("%d\n", ret_sys);
    ret_sys=system("dir /B *.dat");
    printf("%d\n", ret_sys);
}

Results

test.txt
0
File Not Found
1

popen (fake_popen) is NULL and then message "popen failed" apear.

This behaivor does not match with those in gnuplot.exe and wgnuplot_pipes.exe
and it may be fixed.

[Bastian Märkisch]

This is a bug or shortcoming of the "fake" pipe emulation. If the command interpreter cannot execute a command, it returns 1. Currently gnuplot interprets this return value as such and fails. Of course 1 can also be a valid return code by a (more-or-less) successful command, which is the case here. A simple work-around is to force a return value of zero:

flist=system('cmd /c "dir /B *.dat & exit 0"') 

[Bastian Märkisch]

Interestingly, VC and Mingw64 now have their own working implementations of popen/pclose for GUI applications. So we now use them instead of our own emulation.
Fixed in CVS for 5.3, but should be applied to 5.2 and 5.0 after testing, too.

[Tatsuro MATSUOKA]

I have confirmed the fix in CVS. Thanks!

[Bastian Märkisch]

Although it now works in practice with VS2015 and Mingw64, MSDN claims otherwise. Below's a quote from the _popen / _wpopen documentation, see https://msdn.microsoft.com/en-us/library/96ayss4b.aspx :

Note

If used in a Windows program, the _popen function returns an invalid file pointer that causes the program to stop responding indefinitely. _popen works properly in a console application. To create a Windows application that redirects input and output, see Creating a Child Process with Redirected Input and Output in the Windows SDK.

I suppose this has been fixed in recent versions of VC, but documentation hasn't changed yet. So a version check might be in order here.

Tatsuro, do you know which version of VC Kakuto uses for his builds? I vaguely remember that we tried to keep config/msvc/Makfile compliant with VS2010....

[Tatsuro MATSUOKA]

I once heard which version of MSVC Kakuto used but I cannot remember the version. OK I will ask him.

[Tatsuro MATSUOKA]

I found the version information in his web site (written in Japanese). He is using Visual Studio 2010.

[Tatsuro MATSUOKA]

I have recieved a reply from Kakuto. New _wpopen() works on wgnuplot.exe on his build environments.
I have also downloaded his binary from http://ctan.ijs.si/mirror/w32tex/w32/ and confirmed that new pipe works on his wgnuplot.

[Bastian Märkisch]

Thanks, Tatsuro! I too have tested Kakuto's binary, and pipe support seems to work as intended. Changes now applied to 5.0 and 5.2, too.