in reply to What is the preferred cross-platform IPC module?

IO::Pipe ... the lack of support for Windows

This has worked fine for me since (from memory) 5.8.1 or .2; when I helped demerphq fix it:

perl -MIO::Pipe -e"$p=IO::Pipe->new; $p->reader('dir /b'); print while
+ <$p>"

[download]

I'm not sure why the tests are skipped on Win32, but then much of reasoning behind the entire Perl build process is a mystery to me.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Replies are listed 'Best First'.
Re^2: What is the preferred cross-platform IPC module?
by Theory (Beadle) on May 13, 2012 at 22:26 UTC

    Good to know, thanks. Perhaps I should report it as a bug to p5p.

    But I could not see anywhere where it does something with $SIG{PIPE}. I assume that is something I would still have to do myself. I do not want to. I want errors form the child to simply be thrown as exceptions. Is $SIG{PIPE} the only error handler that needs to be installed? And there is no way to lexically scope it, either.

    What I'm thinking of now is some sort of OO interface, call it IPC::Simple, where you instantiate by passing it the command, it does all of the IPC error handling for you, turning stuff into exceptions (not unlike IPC::System::Simple does for system and backticks), and accessors for the STDIN, STDOUT, and STDERR file handles. I Just need STDIN for my current app, but I think a more generally useful Open3-based solution that properly scopes IPC error handling to throw exceptions would be very useful. IPC::Pipe is close-ish, but does not do the error handling stuff, I looks like. AMIRITE?

[reply]
[d/l]
[select]
      But I could not see anywhere where it does something with $SIG{PIPE}.

      Windows doesn't do signals. Perl emulates a few for compatibility, but sigpipe isn't one of them.

      IMO, Windows and *nix/POSIX IPC are just too different to successfully wrap them over in a common interface. I've not found a single 'portable' module that works well on Windows.

      As such, I believe that it is better to move the platform dependency out of the IPC module to the level above, and call a platform specific subroutine to perform the IPC.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?
[reply]
        IMO, Windows and *nix/POSIX IPC are just too different to successfully wrap them over in a common interface. I've not found a single 'portable' module that works well on Windows.

        I disagree. C Std Lib pulls it off. Interix and Cygwin pull it off. Signals on Windows are called Alertable IO. "Safe" signals on Win32 Perl are Windows Messages on the message queue, non-safe signals (CRT Ctrl C and exit) usually will crash the perl interp since they actually run from another thread. On the other land, if you what you mean by "common interface" means "compile and go api compatibility", then no. Regarding POSIX-ish modules working on windows, unless they wrap an external library which already does windows, I agree, there are very few outside the Win32::* namespace that have windows specific code.
[reply]

        Sure, if you know what platform your app will run on. But it's no help for, say, a cross-platform CPAN library.

        Good to know $SIG{PIPE} isn't emulated on Windows. Makes me feel, though, like there is no point in worrying about errors, and I should just assume that everything will work. Annoying, though.

[reply]
[d/l]
Re^2: What is the preferred cross-platform IPC module?
by Theory (Beadle) on May 15, 2012 at 15:31 UTC
    turns out that, for my needs, I need to be able to write to the target's STDIN and read from its STDOUT. I started implementing the module I have been imagining, but it looks like I really should read the IPC::Run docs more closely before I go any further with it. Although its docs say that Win32 support is experimental…
[reply]

      Take a look at winopen2() in Win32::SocketPair.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?
[reply]
[d/l]
        I don't have Windows, and besides, that would completely defeat the purpose: I don't want to have to think about platform issues or any error-handling beyond trapping exceptions. I want a module that does all that for me. I like IPC::System::Simple, for example, which appears to do a nice job of it if all I want to do is system or backticks. IPC::Run may or may not succeed in doing it for interactive IPC, I'm still trying to figure that out.
[reply]
[d/l]

In Section Seekers of Perl Wisdom