in reply to Re^4: open3 and illegal seeks
in thread open3 and illegal seeks

The other changes you suggested do prevent the error from happening.

No, it means an error never occurred in the first place.

What's setting $!?

Some earlier call or some internal call. You could use command line utility strace if you think it's relevant.

I do see how the "or die" on the join could be a logic error

Two problems:

If you *also* want to make sure you received more than zero characters, that's fine. Add that check.

Replies are listed 'Best First'.
Re^6: open3 and illegal seeks
by brainsick (Sexton) on Jul 07, 2009 at 20:15 UTC
    I was including $! in the error text because my Programming Perl, 3rd Edition book has the $! icon next to the readline function which is the implementation of the <FILEHANDLE> operator. If that's incorrect, then I'll omit it from the error message.

    Does this pass muster:
    my $error = ''; if (!eof($PROG_STDERR)) { $error = join('', <$PROG_STDERR>) or die "Error reading data from +STDERR"; } close($PROG_STDERR); print "error: $error\n";
    You've given me some insight into the problem I've been fighting with. Thank you.

      Does this pass muster:

      When a reading error occurs, you don't say which error.

      When the data received doesn't match the data you expected to receive, you incorrectly report a reading error (rather than a protocol error and specifying what you expected to receive).

      Programming Perl, 3rd Edition book has the $! icon next to the readline function

      readline does set $! when an error occurs. Unfortunately, it has no way of letting you know when an error occurred. That's where eof comes into play.

      The docs for readline have been updated for 5.12.

        Since I'm now only reading from $PROG_STDERR when there's data to be read (!eof), reading nothing does indicate an error, right?

        It then stands to reason that the error will be stored in $! since the failure happened during the readline, right?

        If I read between the lines, I think you're saying that by not checking eof after the read, I don't know whether I read all of the data. What conditions would cause me to be able to read some data and then fail midway through? Is that a likely scenario?