in reply to Re^3: Wperl.exe fails with Tk + piped process ( Win32 )
in thread Wperl.exe fails with Tk + piped process ( Win32 )

This code will create a text file called 'test.txt' with the content 'I'm alive' both with perl.exe and wperl.exe:

use IPC::Open2;

#$pid = open2( \*Reader, \*Writer, "notepad.exe" );

open OUTF, ">test.txt";
print OUTF "I'm alive";
close OUTF;

[download]


Now, the following code will do the same (+open a window for notepad.exe) with perl.exe but will FAIL with wperl.exe (the notepad window is opened but NO text file is created). The only difference is that now the Open2 call is not commented out:

use IPC::Open2;

$pid = open2( \*Reader, \*Writer, "notepad.exe" );

open OUTF, ">test.txt";
print OUTF "I'm alive";
close OUTF;

[download]


To me this is proof that with wperl.exe the execution is aborted at the Open2 call.

Replies are listed 'Best First'.
Re^5: Wperl.exe fails with Tk + piped process ( Win32 )
by Corion (Patriarch) on Jan 10, 2012 at 10:36 UTC

    I doubt that a wperl process has STDIN and STDOUT connected. I think that IPC::Open2 tries to do fancy things with (an existing) STDIN and STDOUT.

    Personally, I would try to avoid IPC::Open2 and/or pipe functionality, at least until after having set up STDIN and STDOUT for the child process.

[reply]
[d/l]
      Is there a way to obtain STDIN and STDOUT handles to an EXISTING process (given that the pid is known)?
[reply]

        Not that I'm aware of, at least not on Windows 1.

        The usual way of controlling STDIN and STDOUT of a process is to launch it and supplying your own filehandles for the childs STDIN and STDOUT.

        The "problem" (I assume) with IPC::Open2 is that it tries to clone the current STDIN and STDOUT for the child, which fails in absence of a console with STDIN and STDOUT under wperl.exe. I would try to change that.

        1 I'm aware that you likely can use the ZW APIs, Process Explorer, the Debugger API or some other hackery, but in terms of the Win32 API, I'm not aware of a way to get access to filehandles in other processes without the cooperation of that process.

[reply]
[d/l]

In Section Seekers of Perl Wisdom