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

wperl.exe won't open the console window for the piped process but the app itself crashes anyway

So you say again :) Maybe you'd like to prove it by posting some code?

  • Comment on Re^3: Wperl.exe fails with Tk + piped process ( Win32 )

Replies are listed 'Best First'.
Re^4: Wperl.exe fails with Tk + piped process ( Win32 )
by chessgui (Scribe) on Jan 10, 2012 at 10:30 UTC
    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;


    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;


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

      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.

        Is there a way to obtain STDIN and STDOUT handles to an EXISTING process (given that the pid is known)?