On Feb 23, 2005, at 12:11 PM, Steve Hay wrote:
What do I need to do to test out whether IPC::Open3 is working with pipes or not? (Open3.t doesn't seem to include any such tests.)
I've put that $cmd into the attached test.pl, but something's not right. The IPC::Run version with this new $cmd doesn't work. It gives me the error:That might be a very useful addition to the open3.t tests... Perhaps something like this would work as a test case: "$^X -e'print 1' | $^X -e'print 1 + <>'"
'ARRAY' not allowed as a source for input redirection at test.pl line 68
I think the scan for $special_chars has got confused over the "<>" in the Perl one-liner -- it thinks they are shell redirection characters.
Presumably this would affect other OS's too, and is really a bug in IPC::Cmd?
Hmm, sure seems like it... dang... we have to do some massaging of arguments towards ipc::run when it comes to capturing buffers etc...
Using IPC::Open3 I get the same as "perl -v" gave me before:
err=[0] buffer=[] buferr=[] bufout=[]
and again removing the can_read() calls "fixes" it:
err=[0] buffer=[2] buferr=[] bufout=[2]
That's great news, as it gives us hope that IPC::Open3 + pipes is OK.
That's indeed great news... i'd be much in favour now that if we can get ipc::open3 to work right (basically fixing the can_read call), to just favour that over IPC::Run, meaning one less module that needs to go core.
So the only issue here is that can_read() doesn't work because pipes aren't selectable on Win32. I'm therefore interested what work would be involved (either using C code in the core, or equivalent Perl code in IPC::Cmd) to fix it.The fix to IPC::Cmd is to use another call that DTRT rather than can_read. Ideally of course, can_read is just fixed and IPC::Cmd will be changed to favour IPC::Open3 (newest version) over IPC::Run.
--
Jos Boumans
"If superman is so smart, why does he wear underpants over his trousers?"
CPANPLUS http://cpanplus.sf.net
