>>> This points up my major frustration with Ruby-- I had to completely
>>> guess as to how Open3 worked, or *even that it existed at all*.
>>> There are no docs I can find for it, and this makes developing with
>>> Ruby more of a pain than it needs to be.  If I were doing this in
>>> perl, I'd just have to 'perldoc -q pipe', and instantly I have docs
>>> on
>>> IPC::Open2 and a reference to IPC::Open3 if I need that.
>>
>> Yes, you're right, the documentation should be better. Of course, if
>> you look at open3.rb, you'll see this:
>>
>> # Usage:
>> #	require "open3"
>> #
>> #	in, out, err = Open3.popen3('nroff -man')
>> #  or
>> #	include Open3
>> #	in, out, err = popen3('nroff -man')
>>
>> HOWEVER, this doesn't even work because 'in' is a keyword in Ruby!
>> That, IMHO, should be fixed. (Both this specific case and
>> documentation for libraries in general. However, I obviously don't
>> care *that* much, otherwise I'd be writing documentation right now.)
>>
>> Jason Creighton

Damn %#$^#$ web email client!  %^#@$%@#$

Sorry for the redundant post.  What I was going to say is:

Here's how you can ensure this is fixed:
 * subscribe to ruby-core / ruby-lang.org
 * create a patch to fix that documentation issue (diff -u format, I think)
 * send it to ruby-core, as a "PATCH: ..." subject

It seems heavyweight, but it makes it easier for the maintainer to go
"yep, that looks good, I'll commit that".  And besides, once you've
subscribed, it's easier to contribute more patches!

Of course, for some files, it may be better to send patches directly to
the author, but if the file is in the Ruby distro, ruby-core is a good
catch-all.

Gavin