Re^5: Wperl.exe fails with Tk + piped process ( Win32 )

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.

Comment on Re^5: Wperl.exe fails with Tk + piped process ( Win32 ) Download Code

Replies are listed 'Best First'.
Re^6: Wperl.exe fails with Tk + piped process ( Win32 ) by chessgui (Scribe) on Jan 10, 2012 at 11:02 UTC
Is there a way to obtain STDIN and STDOUT handles to an EXISTING process (given that the pid is known)?	[reply]
Re^7: Wperl.exe fails with Tk + piped process ( Win32 ) by Corion (Patriarch) on Jan 10, 2012 at 12:19 UTC
Not that I'm aware of, at least not on Windows ¹. 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. ¹ 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]
Re^8: Wperl.exe fails with Tk + piped process ( Win32 ) by Anonymous Monk on Jan 10, 2012 at 12:32 UTC
I'm not aware of a way to get access to filehandles in other processes without the cooperation of that process. Shirley alchyol would work ;)	[reply]