Bug 25920 - Kppp terminal and script login problem
Summary: Kppp terminal and script login problem
Status: RESOLVED FIXED
Alias: None
Product: kppp
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Mandrake RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Harri Porten
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-05-20 14:48 UTC by msade
Modified: 2007-12-10 21:38 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description msade 2001-05-20 14:40:41 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           kppp
Version:           KDE 2.1.1 
Severity:          normal
Installed from:    Mandrake RPMs
Compiler:          gcc 2.96
OS:                Linux
OS/Compiler notes: Mandrake 8.0 installation

This is the same as bug report 9162.  Using the current version of KDE 2.1.2 with KPPP version reported as 2.0.3 the first character is still being eaten.

This occurs in both terminal and script logins.  I watched through LoginMultiLineEdit::keyPressEvent and saw that the the character was stored in c through at least the following line
from Modem::modem->writechar(c)
return write(modemfd &c 1) == 1;  

I 

(Submitted via bugs.kde.org)
Comment 1 Harri Porten 2001-05-21 13:42:05 UTC
On 20 May 2001 msade@cs.pitt.edu wrote:

> Package: kppp
> Version: KDE 2.1.1 
> Severity: normal
> Installed from:    Mandrake RPMs
> Compiler:          gcc 2.96
> OS:                Linux
> OS/Compiler notes: Mandrake 8.0 installation
> 
> This is the same as bug report 9162.  Using the current version of KDE 2.1.2 with KPPP version reported as 2.0.3 the first character is still being eaten.
> 
> This occurs in both terminal and script logins.  I watched through LoginMultiLineEdit::keyPressEvent and saw that the the character was stored in c through at least the following line
> from Modem::modem->writechar(c)
> return write(modemfd &c 1) == 1;  

Oh. That looks buggy indeed. I only fixed this issue in writeLine(). Could
you try out the following version of writeChar() ?

bool Modem::writeChar(unsigned char c) {
  int s;
  do {
    s = write(modemfd &c 1) == 1;
    if (s < 0) {
      kdError(5002) << "write() in Modem::writeLine failed" << endl;
      return false;
    }
  } while(s == 0);

  return true;
}

Would be great if it worked as you would have found out a reason for a
problem I couldn't explain for quite some time.

Harri.
Comment 2 msade 2001-05-22 02:56:49 UTC
Tried the substitute for writeChar to no avail.  Since the problem was
still popping up when using a script (as well as the terminal) I ran a
few tests to see what happened.  Here's the summary.

below assume my ID is "myid".  Also assume that the previous line in
the script was "Expect name:" in anticipation of a Username: prompt.
1.  
ID
-------------
actually sends "yid" and newline

2.
Send myid
-------------
actually sends "yid" and newline

3.
Send m
-------------
sends a newline

4.
Send m
Send myid
-------------
sends a newline and then appears to send nothing i.e. the "myid"
doesn't appear to have been sent and there isn't a second newline.


5.
Send m
ID
Expect word:
Password
-------------
This is really odd since it actually sends the letter "m" with a
newline.  Since I'm immediately prompted for my password (which is
noecho) I don't know whether the ID gets sent or not.  A newline is not
sent however and I am prompted by KPPP to enter my password which it
appears to try (since the username is flawed I'm not sure if it is a
successful transfer).

If it wasn't for cases 4 and 5 I would think that the problem existed
in the buffer for modemfd but the behavior is so odd that it seems like
there has to be a better explanation.
Comment 3 George Goldberg 2007-11-08 08:01:00 UTC
Is this bug still present in a recent version of KDE, such as 3.5.8?
Comment 4 J Appel 2007-12-10 21:38:20 UTC
As proposed on http://techbase.kde.org/Contribute/Bugsquad/Bugs_to_be_done this bug is marked as closed (no response within 30 days). If the problem still exists please re-open.