[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Bug in Ruby's PTY extension

ronald braswell

8/6/2007 4:21:00 PM



>From: Daniel Berger <djberg96@gmail.com>
>Reply-To: ruby-talk@ruby-lang.org
>To: ruby-talk@ruby-lang.org (ruby-talk ML)
>Subject: Re: Bug in Ruby's PTY extension
>Date: Mon, 6 Aug 2007 23:19:07 +0900
>
>
>
>On Aug 5, 11:28 am, "ronald braswell" <rpbrasw...@hotmail.com> wrote:
> > I'm new to the ML so please forgive me if this has been discussed
> > previously.
> >
> > Ruby version: 1.8.5
> > OS: Solaris 10 x64 (11/06)
> > CPU: Dual core Opteron
> >
> > When using expect or RExpect I was getting an intermittent premature
> > EOFError on the first call to expect. Catching this exception and then
> > going on was an ugly work around.
> >
> > pty.c:
> >
> > I noticed that Solaris 10 does not support TIOCSCTTY so in function
> > establishShell() the child process closes the slave device and reopens
>it to
> > force it to be the controlling tty. The parent process also closes the
> > slave device because it does not need it. I added a call to nanosleep
>for
> > 20 milliseconds just before the parent process closes the slave fd at
>the
> > end of establishShell() and I now both expect and RExpect work reliably.
> I
> > suspect that just keeping a reference to the open file object in the
>parent
> > process while the child process closes and reopens the slave device
>prevents
> > the EOF from occurring -- but I am far from an expert on Solaris
>internals.
> > This may not be the best way to solve the problem and just adding the
>small
> > delay does not ensure that the problem will never happen again but so
>far,
> > so good.
>
>This quote from comp.programming may be useful:
>
>"In System V, the controlling terminal is the first tty that's opened
>that is not already associated with a session. If you don't want that
>tty to be the controlling terminal, use the O_NOCTTY flag on open().
>
>You don't need the TIOCSCTTY ioctl in SVR4 systems."
>
>http://tinyurl....
>
>Regards,
>
>Dan
>
>
>
>
>
Hi Dan,

The child process inherits open file descriptors for the pty master and
slave devices -- neither of which were the controlling terminal for any
process. In order for the pty slave device to become the controlling
terminal for the child process, the child process needs to call TIOCSCTTY
(not supported for Solaris) or, as you have pointed out, needs to close the
pty slave and reopen it (after calling setsid()). Had Solaris supported
TIOCSCTTY the problem that I experienced probably would not have occured
since the close/open would not have been necessary.

Regards,

Ron

_________________________________________________________________
A new home for Mom, no cleanup required. All starts here.
http://www.reallivemoms.com?ocid=TXT_TAGHM&...