in reply to Usage of IPC::Open2 ...

Says galande:
> if I am giving a wrong command I am getting error.
> But, from then onwards I am not getting output of
> even correct command. what could be wrong ??
You have:
my $cmd = <STDIN>; print Writer $cmd; my $got = <Reader>; print $got;
Suppose $cmd is a bad command. You send it to the shell. Then you try to read from Reader. This waits for the shell to print a line on its stdout. But when $cmd is bad, the shell prints nothing on stdout. Instead, it prints an error message on its stderr. The line my $got = <Reader>; waits for stdout from the shell, but there is none. It waits forever.

This is exactly the problem that is explained in the manual:

This whole affair is quite dangerous, as you may block forever.
That is what has happened to you.

One quick way to fix this: Instead of bash, try bash 2>&1. Then $got will get the error message from bash.

To fix this properly, you would need to use the select function. select will tell you whether Reader has anything to read. Then read from Reader only when there is data available. This is difficult to do right, so I recommend that you try something else first.

Probably the best thing is as repson suggested and forget about IPC::Open2. Use $got = qx{$cmd} instead.

Replies are listed 'Best First'.
Re: Re: Usage of IPC::Open2 ...
by Fastolfe (Vicar) on Nov 26, 2000 at 09:08 UTC
    Note also that IPC::Open3 will do the same thing as open2, but catches stderr also, so that's another option.

    Update: As Dominus kindly pointed out, this does not solve the immediate problem, but if you decide that differentiating between STDERR/STDOUT is something you will end up needing to do with this specific issue or in a future one, IPC::Open3 is something you may wish to look into. Obviously you can't use it as a drop-in replacement for open2 in your code and have things magically work. It's an alternative at more of a design level.

      Says fastolfe:
      > Note also that IPC::Open3 will do the same thing as open2,
      >but catches stderr also, so that's another option.
      It may be another option for someone, but not for galande. Did you read the original question? The problem was that galande is reading from the child's stdout when there is nothing there, and that causes the parent to block. Switching from Open2 to Open3 is not going to make a difference.