From kde-core-devel  Sat Dec 16 11:43:42 2000
From: Geert Jansen <g.t.jansen () stud ! tue ! nl>
Date: Sat, 16 Dec 2000 11:43:42 +0000
To: kde-core-devel
Subject: Re: Bug in PtyProcess ???
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=97696702117113

Michael Matz wrote
 
> > 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.
 
I'm sorry if I'm jumping in a little late. I think there was a bug in
PtyProcess. The terminal is in canonical mode, so if we read less than a line
(defined as no newline at the end), the remote end explicitly flushed the
terminal I/O queues. This is an interesting event and might indicate that the
line is finished, despite the lack of a newline (like /bin/passwd does).
 
I changed  this behavious already last week but I missed this post. (I'm not
subscribed at the moment)
 
Greetings,
Geert