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

List:       kde-core-devel
Subject:    Re: bug in PtyProcess ???
From:       Michael Matz <matz () ifh ! de>
Date:       2000-12-09 5:02:15
[Download RAW message or body]

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.

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