[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: bug in PtyProcess ???
From:       Andre Charbonneau <yoamwmvs () umail ! corel ! com>
Date:       2000-12-11 14:48:28
[Download RAW message or body]

Michael Matz wrote:

> Hi,
> 
> On Tue, 12 Dec 2000, Andre Charbonneau wrote:
> > >
> > > Isn't the current behaviour, the behaviour you would expect from a
> > > readLine function? This is also what the comment states:
> 
> Exactly.
> 
> > I understand what you are saying.  But still I thing there is a bug in
> > PtyProcess.  What happened is that during the first readLine call, a
> > line like the following was read inside PtyProcess's buffer:
> > [Changing password for andrec\ncurrent (UNIX) password:]
> > The first PtyProcess::readLine function call returnes the following:
> > [Changing password for andrec]
> 
> This is correct, as this is really the first line.
> 
> > And the rest of the line stayed in the buffer.  This causes the next
> > PtyProcess::readLine to hang (on the system call read()) since what is
> 
> which of course also is understandable. There is no \n yet in the buffer,
> buf by calling readLine() the user explicitely requested one. So it wait
> for more input until a \n arrives. If you don't want that behaviour the
> block parameter is for you.
> 
> > My modifications to PtyProcess make the next PtyProcess::readLine
> > function return the following:
> > [current (UNIX) password:]
> 
> But this would break the normal contract of this routine, if the input
> arrives in chunks (say, when the remote client send byte by byte). In this
> case readLine _has_ to wait until a \n arrives unless the block argument
> is false.
> 
> > 1. Leave the PtyProcess like it is and not use it for commands that
> > contains prompts that are not ending with a \n character.
> > 2. Modify PtyProcess so that when a readLine call is made, if the
> > internal buffer contains something, then return it, else use the
> > system read() call to get the next input.
> 
> 3. Leave PtyProcess as it is, thereby not breaking it, and use it
>    correctly even for prompts not containing '\n'.
> 
> If you don't want blocking on your second readLine() (as it seems), then
> why don't you set the 'block' argument to false?
> 
> 
> Ciao,
> Michael.
> 

Ok, I understand what you are saying Michael.  I will therefore leave 
PtyProcess as it is.  I guess I got confused because on my system, 
kchangepwd, which uses PtyProcess, hangs after I enter my password on the 
first dialog.  I tought that there was a bug in PtyProcess but I guess the 
bug is really in kchangepwd instead.

What do you think about the 'expect' scripting language?  Do you think it 
would be a better choice then to use PtyProcess for interactive utilities 
like 'passwd' ?  It looks pretty simple to use but my main concern is 
security...

Thanks,
-- 
Andre Charbonneau
GNU Linux software developer - Globalization
Corel Corporation
-- 
The address in the headers is not the poster's real email address.  Do not send
private mail to the poster using your mailer's "reply" feature.  CC's of mail 
to mailing lists are OK.  Problem reports to "postmaster@umail.corel.com".  
The poster's email address is "andrec@corel.com".

[prev in list] [next in list] [prev in thread] [next in thread]