in reply to IPC::Open3 not connecting network socket handle

You can do that without using IPC::Open3:
my $new_sock = $sock->accept() or die "No one came!"; my $pid = fork; defined $pid or die "unable to fork"; if (!$pid) { open STDIN, '<&', $new_sock or exit(1); open STDOUT, '>&', $new_sock or exit(1); exec "/bin/cat"; exit(1); } waitpid( $pid, 0 );

Replies are listed 'Best First'.
Re^2: IPC::Open3 not connecting network socket handle
by ikegami (Patriarch) on Jul 24, 2009 at 07:19 UTC
    Sure, but it's longer, it removes or reduces error checking, and it lowers portability. (Granted, the last was already lost in this case, but it means you have two things to fix instead of one if you ever want portability.) Also, reinventing the wheel leads to problems such as using exit instead of _exit.
      well, mostly, I agree with what you say, but...

      This bug in IPC::Open3 that was only solved during the 5.8.x series has beating me a couple of times. If you want your script to work with older perls you have to put in place a workaround that will remove the shorten code advantage.

      IPC::Open3 inners are very complex. If something goes wrong there, debugging it could be a nightmare.

      Finally, I don't like this reminiscent 2-args-open syntax "<&FOO" that doesn't play well with lexical file handles. Using "<&".fileno($new_sock) is, well, ugly at least.

      So, considering all of this, I don't see IPC::Open3 as a clear winner when compared with the code in my previous post.

        IPC::Open3 inners are very complex. If something goes wrong there, debugging it could be a nightmare.

        It's actually very straightforward if you enough to roll out your own solution. You can't have it both ways. It's either too complex to roll out your own solution, or it's easy to debug.

        Using "<&".fileno($new_sock) is, well, ugly at least.

        Yeah, and he was fortunate he didn't need to use gensym in this case.