Kudos to documentors: (popen2)
tchrist at mox.perl.com
Thu Aug 19 17:33:38 CEST 1999
[courtesy cc of this posting mailed to cited author]
Robb Shecter <shecter at darmstadt.gmd.de> writes:
:I needed to do some system programming, and at first tried to use
:Perl. Although I've used Perl for years, this documentation page
:forced me to give Python a try for it:
The standard documentation for Perl is found in manpages, not
on the web. That's an old copy.
would have answered it.
:(Just notice how much is implicit, and not documented, and with no
:links to other needed info.)
I have no idea what you're talking about, or what links you're
looking for, but as the original author of that module, I am
always happy to accept documentation suggestions.
Or is this just another case of pissing on something that you didn't
understand out of the way of the people responsible? If so, you lose,
because *I'm* responsible. What's your biggest problem?
And remember, Perl's documentation is NOT WEB-BASED. That's
merely an automatic conversion, and suffers various faults
because of that. It is not maintained in that form, nor does
it cater to it.
Admittedly the docs for open2 there in the module are very sparse.
Did you read the section on "Bidirectional Communication with Another
Process" in the standard perlipc manpage, which is the standard tutorial
for doing interprocess communication in Perl? Here's a relevant excerpt:
Bidirectional Communication with Another Process
While this works reasonably well for unidirectional communication,
what about bidirectional communication? The obvious thing you'd
like to do doesn't actually work:
open(PROG_FOR_READING_AND_WRITING, "| some program |")
and if you forget to use the -w flag, then you'll miss out entirely
on the diagnostic message:
Can't do bidirectional pipe at -e line 1.
If you really want to, you can use the standard open2() library
function to catch both ends. There's also an open3() for
tridirectional I/O so you can also catch your child's STDERR,
but doing so would then require an awkward select() loop and
wouldn't allow you to use normal Perl input operations.
If you look at its source, you'll see that open2() uses low-level
primitives like Unix pipe() and exec() calls to create all the
connections. While it might have been slightly more efficient by
using socketpair(), it would have then been even less portable than
it already is. The open2() and open3() functions are unlikely to
work anywhere except on a Unix system or some other one purporting
to be POSIX compliant.
Here's an example of using open2():
$pid = open2(*Reader, *Writer, "cat -u -n" );
Writer->autoflush(); # default here, actually
print Writer "stuff\n";
$got = <Reader>;
The problem with this is that Unix buffering is really going to
ruin your day. Even though your Writer filehandle is auto-flushed,
and the process on the other end will get your data in a timely
manner, you can't usually do anything to force it to give
it back to you in a similarly quick fashion. In this case,
we could, because we gave cat a -u flag to make it unbuffered.
But very few Unix commands are designed to operate over pipes,
so this seldom works unless you yourself wrote the program on
the other end of the double-ended pipe.
The section following that one is on "Bidirectional Communication with
Yourself", which discusses Perl's forking open call. You can also
learn about this in the recently added perlopentut manpage, which is
a tutorial on how to open various things. Sounds like you could use a
bit of a tutorial.
Next time, please try the manpages, and send the authors mail or file a
bug report. But please don't just piss on people where you think they
can't see you. Sheesh.
Those who do not fight the demons within themselves are destined to fight them
More information about the Python-list