From djberg96 at yahoo.com  Wed Feb  1 19:39:47 2006
From: djberg96 at yahoo.com (Daniel Berger)
Date: Wed, 1 Feb 2006 16:39:47 -0800 (PST)
Subject: [Win32utils-devel] Fwd: win32-clipboard and Unicode zero bytes
Message-ID: <20060202003947.24122.qmail@web50315.mail.yahoo.com>

Hi all,

I'm forwarding this message from Brian Marick.  If you
run this test script and then paste the results into a
Unicode aware text editor, you'll notice that it only
prints one character instead of three.

I tried changing the strlen to _tcslen and strcpy to
_tcscpy, but that didn't help.  I mucked around a bit
with the MultiByteToWideChar function, too, but didn't
have any luck.

Any ideas?

Thanks,

Dan 

# test.rb
$:.unshift Dir.pwd
require 'clipboard'

def unicopy(hex_name_array)
 
Win32::Clipboard.set_data(win32unicode(hex_name_array),
                           
Win32::Clipboard::UNICODETEXT)
  true
end


def extract_flipped_bytes(unicode_char_string)
  [unicode_char_string[2,2].to_i(16),
    unicode_char_string[0,2].to_i(16)]
end


def win32unicode(unicode_char_strings)
  flipped_bytes = unicode_char_strings.collect do |
str |
    extract_flipped_bytes(str)
  end
  flipped_bytes.flatten.pack('C*')
end

puts unicopy(%w{ 0401 0400 0402 })

Note: forwarded message attached.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An embedded message was scrubbed...
From: Brian Marick <marick at exampler.com>
Subject: win32-clipboard and Unicode zero bytes
Date: Mon, 30 Jan 2006 23:18:21 -0600
Size: 2677
Url: http://rubyforge.org/pipermail/win32utils-devel/attachments/20060201/0d798d05/attachment.eml

From phasis at nownuri.net  Thu Feb  2 07:07:16 2006
From: phasis at nownuri.net (Park Heesob)
Date: Thu, 2 Feb 2006 21:07:16 +0900
Subject: [Win32utils-devel] Fwd: win32-clipboard and Unicode zero bytes
References: <20060202003947.24122.qmail@web50315.mail.yahoo.com>
Message-ID: <002901c627f1$38551720$6d7ba8c0@2xnm9896kmqn5b9>

Hi,
----- Original Message ----- 
From: "Daniel Berger" <djberg96 at yahoo.com>
To: <win32utils-devel at rubyforge.org>
Sent: Thursday, February 02, 2006 9:39 AM
Subject: [Win32utils-devel] Fwd: win32-clipboard and Unicode zero bytes


> Hi all,
>
> I'm forwarding this message from Brian Marick.  If you
> run this test script and then paste the results into a
> Unicode aware text editor, you'll notice that it only
> prints one character instead of three.
>
> I tried changing the strlen to _tcslen and strcpy to
> _tcscpy, but that didn't help.  I mucked around a bit
> with the MultiByteToWideChar function, too, but didn't
> have any luck.
>
> Any ideas?
>
> Thanks,
>
> Dan
>

Here is some patches of clipboard.c

Line 70:
   hMem = GlobalAlloc(GHND, strlen(data) + sizeof(TCHAR*));
to
   hMem = GlobalAlloc(GHND, RSTRING(rbData)->len + sizeof(TCHAR*));

Line 75:
   strcpy((TCHAR *)GlobalLock(hMem), data);
to
   memcpy((TCHAR *)GlobalLock(hMem), data, RSTRING(rbData)->len);

HTH,

Park Heesob








From Daniel.Berger at qwest.com  Thu Feb  2 11:29:07 2006
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Thu, 2 Feb 2006 10:29:07 -0600
Subject: [Win32utils-devel] Fwd: win32-clipboard and Unicode zero bytes
Message-ID: <39AA6550E5AA554AB1456707D6E5563DBCFE05@QTOMAE2K3M01.AD.QINTRA.COM>

> -----Original Message-----
> From: win32utils-devel-bounces at rubyforge.org 
> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of 
> Park Heesob
> Sent: Thursday, February 02, 2006 5:07 AM
> To: Development and ideas for win32utils projects
> Subject: Re: [Win32utils-devel] Fwd: win32-clipboard and 
> Unicode zero bytes

<snip>

> Here is some patches of clipboard.c
> 
> Line 70:
>    hMem = GlobalAlloc(GHND, strlen(data) + sizeof(TCHAR*));
> to
>    hMem = GlobalAlloc(GHND, RSTRING(rbData)->len + sizeof(TCHAR*));
> 
> Line 75:
>    strcpy((TCHAR *)GlobalLock(hMem), data);
> to
>    memcpy((TCHAR *)GlobalLock(hMem), data, RSTRING(rbData)->len);
> 
> HTH,
> 
> Park Heesob

Works great, thanks!  Please commit.

Dan


From djberg96 at gmail.com  Thu Feb  2 19:28:59 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Thu, 02 Feb 2006 17:28:59 -0700
Subject: [Win32utils-devel] Fwd: win32-clipboard and Unicode zero bytes
In-Reply-To: <39AA6550E5AA554AB1456707D6E5563DBCFE05@QTOMAE2K3M01.AD.QINTRA.COM>
References: <39AA6550E5AA554AB1456707D6E5563DBCFE05@QTOMAE2K3M01.AD.QINTRA.COM>
Message-ID: <43E2A3CB.5020001@gmail.com>

Berger, Daniel wrote:

>>-----Original Message-----
>>From: win32utils-devel-bounces at rubyforge.org 
>>[mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of 
>>Park Heesob
>>Sent: Thursday, February 02, 2006 5:07 AM
>>To: Development and ideas for win32utils projects
>>Subject: Re: [Win32utils-devel] Fwd: win32-clipboard and 
>>Unicode zero bytes
>>    
>>
>
><snip>
>
>  
>
>>Here is some patches of clipboard.c
>>
>>Line 70:
>>   hMem = GlobalAlloc(GHND, strlen(data) + sizeof(TCHAR*));
>>to
>>   hMem = GlobalAlloc(GHND, RSTRING(rbData)->len + sizeof(TCHAR*));
>>
>>Line 75:
>>   strcpy((TCHAR *)GlobalLock(hMem), data);
>>to
>>   memcpy((TCHAR *)GlobalLock(hMem), data, RSTRING(rbData)->len);
>>
>>HTH,
>>
>>Park Heesob
>>    
>>
>
>Works great, thanks!  Please commit.
>
>Dan
>
>_______________________________________________
>win32utils-devel mailing list
>win32utils-devel at rubyforge.org
>http://rubyforge.org/mailman/listinfo/win32utils-devel
>
>  
>
Nevermind, I'll commit it now and put out a new release shortly.

Here's a question for everyone, though - in the age of Unicode, is 
strcpy obsolete?  Should we always use memcpy?

Dan

From phasis at nownuri.net  Fri Feb  3 01:03:11 2006
From: phasis at nownuri.net (Park Heesob)
Date: Fri, 3 Feb 2006 15:03:11 +0900
Subject: [Win32utils-devel] Fwd: win32-clipboard and Unicode zero bytes
In-Reply-To: <43E2A3CB.5020001@gmail.com>
References: <39AA6550E5AA554AB1456707D6E5563DBCFE05@QTOMAE2K3M01.AD.QINTRA.COM>
	<43E2A3CB.5020001@gmail.com>
Message-ID: <20060203055534.M88987@nownuri.net>

Hi,
On Thu, 02 Feb 2006 17:28:59 -0700, Daniel Berger wrote
> Berger, Daniel wrote:
> 
> >>-----Original Message-----
> >>From: win32utils-devel-bounces at rubyforge.org 
> >>[mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of 
> >>Park Heesob
> >>Sent: Thursday, February 02, 2006 5:07 AM
> >>To: Development and ideas for win32utils projects
> >>Subject: Re: [Win32utils-devel] Fwd: win32-clipboard and 
> >>Unicode zero bytes
> >>    
> >>
> >
> ><snip>
> >
> >  
> >
> >>Here is some patches of clipboard.c
> >>
> >>Line 70:
> >>   hMem = GlobalAlloc(GHND, strlen(data) + sizeof(TCHAR*));
> >>to
> >>   hMem = GlobalAlloc(GHND, RSTRING(rbData)->len + sizeof(TCHAR*));
> >>
> >>Line 75:
> >>   strcpy((TCHAR *)GlobalLock(hMem), data);
> >>to
> >>   memcpy((TCHAR *)GlobalLock(hMem), data, RSTRING(rbData)->len);
> >>
> >>HTH,
> >>
> >>Park Heesob
> >>    
> >>
> >
> >Works great, thanks!  Please commit.
> >
> >Dan
> >
> Nevermind, I'll commit it now and put out a new release shortly.
> 
> Here's a question for everyone, though - in the age of Unicode, is 
> strcpy obsolete?  Should we always use memcpy?
> 
> Dan

Refer to http://www.tbray.org/ongoing/When/200x/2003/04/26/UTF
         http://www.i18nguy.com/unicode/c-unicode.html
         http://www.marin.clara.net/tips/unicode_tips.htm

You can use strcpy and strlen in case of UTF-8, but cannot use in UTF-16, UTF-32 etc.
In Unicode environment, you should use wcscpy and wcslen instead of strcpy and strlen.

Regards,

Park Heesob






From djberg96 at gmail.com  Fri Feb  3 01:46:59 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Thu, 02 Feb 2006 23:46:59 -0700
Subject: [Win32utils-devel] Fwd: win32-clipboard and Unicode zero bytes
In-Reply-To: <20060203055534.M88987@nownuri.net>
References: <39AA6550E5AA554AB1456707D6E5563DBCFE05@QTOMAE2K3M01.AD.QINTRA.COM>	<43E2A3CB.5020001@gmail.com>
	<20060203055534.M88987@nownuri.net>
Message-ID: <43E2FC63.8070808@gmail.com>

Park Heesob wrote:

>Hi,
>On Thu, 02 Feb 2006 17:28:59 -0700, Daniel Berger wrote
>  
>
>>Berger, Daniel wrote:
>>
>>    
>>
>>>>-----Original Message-----
>>>>From: win32utils-devel-bounces at rubyforge.org 
>>>>[mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of 
>>>>Park Heesob
>>>>Sent: Thursday, February 02, 2006 5:07 AM
>>>>To: Development and ideas for win32utils projects
>>>>Subject: Re: [Win32utils-devel] Fwd: win32-clipboard and 
>>>>Unicode zero bytes
>>>>   
>>>>
>>>>        
>>>>
>>><snip>
>>>
>>> 
>>>
>>>      
>>>
>>>>Here is some patches of clipboard.c
>>>>
>>>>Line 70:
>>>>  hMem = GlobalAlloc(GHND, strlen(data) + sizeof(TCHAR*));
>>>>to
>>>>  hMem = GlobalAlloc(GHND, RSTRING(rbData)->len + sizeof(TCHAR*));
>>>>
>>>>Line 75:
>>>>  strcpy((TCHAR *)GlobalLock(hMem), data);
>>>>to
>>>>  memcpy((TCHAR *)GlobalLock(hMem), data, RSTRING(rbData)->len);
>>>>
>>>>HTH,
>>>>
>>>>Park Heesob
>>>>   
>>>>
>>>>        
>>>>
>>>Works great, thanks!  Please commit.
>>>
>>>Dan
>>>
>>>      
>>>
>>Nevermind, I'll commit it now and put out a new release shortly.
>>
>>Here's a question for everyone, though - in the age of Unicode, is 
>>strcpy obsolete?  Should we always use memcpy?
>>
>>Dan
>>    
>>
>
>Refer to http://www.tbray.org/ongoing/When/200x/2003/04/26/UTF
>         http://www.i18nguy.com/unicode/c-unicode.html
>         http://www.marin.clara.net/tips/unicode_tips.htm
>
>You can use strcpy and strlen in case of UTF-8, but cannot use in UTF-16, UTF-32 etc.
>In Unicode environment, you should use wcscpy and wcslen instead of strcpy and strlen.
>
>Regards,
>
>Park Heesob
>  
>
But, with UNICODE defined, doesn't _tcscpy and _tcslen use wcscpy and 
wcslen behind the scenes?  Based on a comment from someone else it looks 
like the issue is with multibyte character sets, in which case MBCS 
needs to be defined in order for the tchar functions to handle this 
situation correctly?

Is there any downside to just defining MBCS (instead of UNICODE) in all 
C extensions for Windows?

Thanks for the links, btw.

Regards,

Dan

From djberg96 at gmail.com  Fri Feb  3 21:14:06 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Fri, 03 Feb 2006 19:14:06 -0700
Subject: [Win32utils-devel] Pure Ruby version of win32-clipboard
Message-ID: <43E40DEE.8030909@gmail.com>

Hi all,

In CVS you'll find a clipboard.rb file.  I hadn't touched it in a while 
until recently.  However, it doesn't seem to actually work.  Calling 
set_data doesn't fail, but it doesn't actually seem to set the clipboard 
data.

Any ideas?

Thanks,

Dan

From noreply at rubyforge.org  Wed Feb  8 12:29:08 2006
From: noreply at rubyforge.org (noreply@rubyforge.org)
Date: Wed, 8 Feb 2006 10:29:08 -0700
Subject: [Win32utils-devel] [ win32utils-Feature Requests-3502 ] Allow
	win32-open3 to take a block
Message-ID: <200602081729.k18HT85l010642@rubyforge.org>

Feature Requests item #3502, was opened at 2006-02-08 10:29
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=414&aid=3502&group_id=85

Category: win32-open3
Group: Code
Status: Open
Resolution: None
Priority: 4
Submitted By: Daniel Berger (djberg96)
Assigned to: Park Heesob  (phasis68)
Summary: Allow win32-open3 to take a block

Initial Comment:
I think we should allow win32-open3's methods to take a block in the way that the Unix open3 module works, e.g.

Open3.popen3(cmd){ |cmd_in, cmd_out, cmd_err|
   # ...
}

Each pipe should be closed via ensure as open3.rb does.  This keeps the API compatible with the current Ruby API, and is probably a better way to use the module in general (since the pipes are guaranteed to be closed at the end of the block).

Regards,

Dan

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=414&aid=3502&group_id=85

From noreply at rubyforge.org  Wed Feb  8 19:42:05 2006
From: noreply at rubyforge.org (noreply@rubyforge.org)
Date: Thu, 9 Feb 2006 09:42:05 +0900
Subject: [Win32utils-devel] [ win32utils-Feature Requests-3502 ] Allow
	win32-open3 to take a block
Message-ID: <200602090042.k190g5jF030982@rubyforge.org>

Feature Requests item #3502, was opened at 2006-02-09 02:29
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=414&aid=3502&group_id=85

Category: win32-open3
Group: Code
>Status: Closed
Resolution: None
Priority: 4
Submitted By: Daniel Berger (djberg96)
Assigned to: Park Heesob  (phasis68)
Summary: Allow win32-open3 to take a block

Initial Comment:
I think we should allow win32-open3's methods to take a block in the way that the Unix open3 module works, e.g.

Open3.popen3(cmd){ |cmd_in, cmd_out, cmd_err|
   # ...
}

Each pipe should be closed via ensure as open3.rb does.  This keeps the API compatible with the current Ruby API, and is probably a better way to use the module in general (since the pipes are guaranteed to be closed at the end of the block).

Regards,

Dan

----------------------------------------------------------------------

>Comment By: Park Heesob  (phasis68)
Date: 2006-02-09 09:42

Message:
I modified and committed for your request.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=414&aid=3502&group_id=85

From djberg96 at yahoo.com  Sun Feb 19 20:39:32 2006
From: djberg96 at yahoo.com (Daniel Berger)
Date: Sun, 19 Feb 2006 17:39:32 -0800 (PST)
Subject: [Win32utils-devel] Fwd: Win32::Daemon, Problems with service_stop
Message-ID: <20060220013932.89522.qmail@web50315.mail.yahoo.com>

Anyone want to take a stab at this?  I've brought it
up before but it's been a while.

Dan


Note: forwarded message attached.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An embedded message was scrubbed...
From: "Luis Lavena" <luislavena at gmail.com>
Subject: Win32::Daemon, Problems with service_stop
Date: Sun, 19 Feb 2006 16:14:43 -0300
Size: 2641
Url: http://rubyforge.org/pipermail/win32utils-devel/attachments/20060219/1e4db8d0/attachment.eml

From phasis at nownuri.net  Mon Feb 20 09:30:59 2006
From: phasis at nownuri.net (Park Heesob)
Date: Mon, 20 Feb 2006 23:30:59 +0900
Subject: [Win32utils-devel] Fwd: Win32::Daemon,
	Problems with service_stop
In-Reply-To: <20060220013932.89522.qmail@web50315.mail.yahoo.com>
References: <20060220013932.89522.qmail@web50315.mail.yahoo.com>
Message-ID: <20060220142243.M36348@nownuri.net>

Hi,

On Sun, 19 Feb 2006 17:39:32 -0800 (PST), Daniel Berger wrote
> Anyone want to take a stab at this?  I've brought it
> up before but it's been a while.
> 
> Dan
> 
> Note: forwarded message attached.
> 
As you know,the win32-service is multithreaded application.
But, Ruby's sleep or select is not compatible with the Thread of Windows.
While executing sleep or select in ruby code,the other thread cannot do anything.

To workaround this stopping problem, 

1. Use loop of short sleep insthead of long sleep.
ex) 10.times { sleep 1 } instead of sleep 10

2. Use nonblocking IO and socket.

Regards,

Park Heesob


From luislavena at gmail.com  Mon Feb 20 14:43:28 2006
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 20 Feb 2006 16:43:28 -0300
Subject: [Win32utils-devel] Win32 service and blocking code in service_main
Message-ID: <71166b3b0602201143j29b37df7gee1123f142bcf03b@mail.gmail.com>

Hello mailing list!

Sorry for the personal/private mail I sent to Daniel and Park, but
just a few minutes ago I subscribed to this list.

I have found the solution, for webrick, mongrel and other webserver
(well I guess).

If the code in service_main is blocked (like the webrick dispatcher),
the service_main function never exit/left, so service.mainloop never
terminates and service control timeout.

What I have done is put the running dispatcher in a Thread that is
fired by service_main, and then I loop (like you have said Park) using
small sleep values until state != RUNNING, which is signaled during a
stop command.

Now mongrel and webrick start and stop without problems, from
controller script or using the Services console (or command line "net
start/stop").

Because mongrel dispatch working threads, there is no need to create
another one that join with them, just I have added comments to the
code that could be useful with webrick too.

Regards and thank you for your time,

Luis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mongrel_simple_service.rb
Type: application/octet-stream
Size: 3738 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/win32utils-devel/attachments/20060220/1e0d7bee/mongrel_simple_service-0001.obj

From luislavena at gmail.com  Wed Feb 22 13:07:54 2006
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 22 Feb 2006 15:07:54 -0300
Subject: [Win32utils-devel] win32-service as binary gem offered from mongrel
Message-ID: <71166b3b0602221007k755c667bs26ca5b091d8ca226@mail.gmail.com>

Hello mailing list!

Well, been working on mongrel project to provide win32 services for rails.

Still needed to solve a few threading issues as noted by Park, but
even with errors, works so we wanted to release inott he wild to get
feedback.

To smooth the gem installation of mongrel, we created (and made
available at mongrel project) a win32-service gem in binary form,
included as dependency in mongrel gem.

We hope this is ok, in any case the Rakefile is available so could be
included in win32utils CVS and be used by you to update your
win32-service (in case progress isn't stalled).

Anyway, thank you guys for your contribution (mean service stuff),
help and replies about our problems.

Later,

--
Luis


From djberg96 at gmail.com  Sun Feb 26 18:10:42 2006
From: djberg96 at gmail.com (Daniel Berger)
Date: Sun, 26 Feb 2006 16:10:42 -0700
Subject: [Win32utils-devel] A quick announcement
Message-ID: <44023572.2060501@gmail.com>

Hi all,

In light of Curt's decision to use VC++ 6 to build the latest one click 
installer, along with what are undoubtedly future compatibility problems 
between old and new compilers, I think it's best if we try to move over 
the simpler packages to a pure Ruby solution using Win32API.  I have 
started that process by releasing pure Ruby versions of win32-clipboard 
and win32-sound.

In addition, I've started the process of moving these packages into the 
toplevel CVS directory, instead of under a common win32utils directory.  
The latter falls into the 'it seemed like a good idea at the time' 
category, where I thought it would make creating a single distro 
easier.  Now I just think it's a pain.  So, over the course of the next 
couple months I'll be moving stuff around.

I'm sure some of you are thinking, "I told you so" right about now.  My 
apologies in advance for the nuisance. 

Regards,

Dan

From sdate at everestkc.net  Sun Feb 26 19:11:38 2006
From: sdate at everestkc.net (Shashank Date)
Date: Sun, 26 Feb 2006 18:11:38 -0600
Subject: [Win32utils-devel] A quick announcement
In-Reply-To: <44023572.2060501@gmail.com>
References: <44023572.2060501@gmail.com>
Message-ID: <440243BA.50705@everestkc.net>

Hi Dan,

Daniel Berger wrote:

>In light of Curt's decision to use VC++ 6 to build the latest one click 
>installer, along with what are undoubtedly future compatibility problems 
>between old and new compilers, I think it's best if we try to move over 
>the simpler packages to a pure Ruby solution using Win32API.  I have 
>started that process by releasing pure Ruby versions of win32-clipboard 
>and win32-sound.
>  
>

I for one like that idea! How stable do you think is Win32 API? For some 
reason I was under the impression that we chose not to use Win32 API 
because of some issue we had in the earlier version. I could be wrong 
though. Also, what about ruby/dl as an option?

>In addition, I've started the process of moving these packages into the 
>toplevel CVS directory, instead of under a common win32utils directory.  
>The latter falls into the 'it seemed like a good idea at the time' 
>category, where I thought it would make creating a single distro 
>easier.  Now I just think it's a pain.  So, over the course of the next 
>couple months I'll be moving stuff around.
>  
>

I may be able to help you there.

>I'm sure some of you are thinking, "I told you so" right about now.  
>

I told you so :-)

>My apologies in advance for the nuisance. 
>  
>

Oh no. No apologies needed ... you did what you thought was the best. 
And did (are doing) a wonderful job of keeping them utilities coming.

>Regards,
>
>Dan
>
Looking forward,
-- shanko


From noreply at rubyforge.org  Thu Feb  9 21:24:38 2006
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 10 Feb 2006 02:24:38 -0000
Subject: [Win32utils-devel] [ win32utils-Feature Requests-3502 ] Allow
	win32-open3 to take a block
Message-ID: <200602100224.k1A2ObCw008744@rubyforge.org>

Feature Requests item #3502, was opened at 2006-02-08 10:29
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=414&aid=3502&group_id=85

Category: win32-open3
Group: Code
Status: Closed
>Resolution: Accepted
Priority: 4
Submitted By: Daniel Berger (djberg96)
Assigned to: Park Heesob  (phasis68)
Summary: Allow win32-open3 to take a block

Initial Comment:
I think we should allow win32-open3's methods to take a block in the way that the Unix open3 module works, e.g.

Open3.popen3(cmd){ |cmd_in, cmd_out, cmd_err|
   # ...
}

Each pipe should be closed via ensure as open3.rb does.  This keeps the API compatible with the current Ruby API, and is probably a better way to use the module in general (since the pipes are guaranteed to be closed at the end of the block).

Regards,

Dan

----------------------------------------------------------------------

>Comment By: Daniel Berger (djberg96)
Date: 2006-02-09 19:24

Message:
Excellent!  Thank you!

----------------------------------------------------------------------

Comment By: Park Heesob  (phasis68)
Date: 2006-02-08 17:42

Message:
I modified and committed for your request.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=414&aid=3502&group_id=85