>> 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)
>
> Nitpick: unified diffs here, although shorter, can often less, umm,
> informative and unless specifically asked for, I would suggest sending
> in both a non-unified and a unified diff.

I've never seen two diffs sent before, and I believe the standard on
ruby-core (I'm not a licenced representative, BTW :) is unified.  I've
seen a complaint when a plain diff was sent.

> Also, it is not a patch file, until it has been applied :)

That's a new one :/

Isn't the output of 'diff' considered fair game as input to 'patch'? 
Don't uber-geeks simply run 'patch' on the entire contents of an email and
trust it to do the right thing?

>>  * 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!
>
> Given Jason's busy workload (I would imagine) I doubt he will be able to
> contribute that many (if any) patches.

The suggested patch would take less than 5 minutes.  It might not seem
like much of an outcome, but the maintainer, on applying it, would
probably be prompted to do some general improvement to the file.

>> 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.
>
> Since you are such an advocate in creating patches and the like, perhaps
> you would send one in? :)

Well, I'm up to my eyeballs with other Ruby documentation concerns, and
not even achieving that much.  And I have no personal concern for popen3,
or whatever the issue is.  But I'll see what I can do.

Gavin