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

List:       konsole-devel
Subject:    Re: [Konsole-devel] [Bug 105824] ctrl-d doesn't always work
From:       lars.doelle () on-line ! de
Date:       2006-07-05 0:10:01
Message-ID: 200607050210.02464.lars.doelle () on-line ! de
[Download RAW message or body]

> It is unlikely to get fixed unless there is someone to reproduce it...   

The problem is unlikely to be caused by the konsole.  It is not the
konsole, that treats the ctrl-d different, but the client (program) resp.
the program in connection with the line discipline.

Citing man:termios
-----
       VEOF   (004,  EOT, Ctrl-D) End-of-file character.  More precisely: this \
                character causes the pending tty buffer to be sent to the waiting \
                user pro-
              gram without waiting for end-of-line.  If it is the first character of \
                the line, the read() in the user program returns 0,  which  signifies
              end-of-file.  Recognized when ICANON is set, and then not passed as \
                input.
-----
so it may have something to do whether you are at the begin of a line, or not, \
perhaps.

You can see the current discipline via "stty -a".

What makes this stuff so obscure, is that you have a stack of ptys and terminal
lines, really, i.e. konsole, bash, ssh, sshd, bash, ... where all the line \
disciplines on the stack are involved to finally cause your application to terminate \
eventually.

Responsible for the termination is the very last terminal line and the very last line
discipline setting program on the stack (shell, i.e.), since the other should all be \
raw, transparently passing ctrl-d forward, so whatever is done on the ssh'd side is \
the origin of the problem. The problem should be locally reproducible, cutting the \
stack shorter.

For those who can reproduce problem (locally or remotely), i would thus suggest to
try to use a different terminal emulation, e.g. xterm or linux-console, which should
expose precisely the same behaviour, because they are plainly not involved in the
issue.

-lars
_______________________________________________
konsole-devel mailing list
konsole-devel@kde.org
https://mail.kde.org/mailman/listinfo/konsole-devel


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