From owner-freebsd-bugs Sat Dec 7 12:00:03 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA08247 for bugs-outgoing; Sat, 7 Dec 1996 12:00:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA08236; Sat, 7 Dec 1996 12:00:01 -0800 (PST) Date: Sat, 7 Dec 1996 12:00:01 -0800 (PST) Message-Id: <199612072000.MAA08236@freefall.freebsd.org> To: freebsd-bugs Cc: From: Garrett Wollman Subject: bin/1037 Reply-To: Garrett Wollman Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR bin/1037; it has been noted by GNATS. From: Garrett Wollman To: uhclem@nemesis.lonestar.org (Frank Durda IV) Cc: freebsd-gnats-submit@freefall.freebsd.org Subject: bin/1037 Date: Sat, 7 Dec 1996 14:54:00 -0500 < 5. Telnet self > 6. login (same csh/filec login used in steps 1-5) > 7. cd directory where above programs reside. > 8. Type [c][CTRL][D] > system should display files that match, but instead, simply > echos ^D. MALFUNCTION > As above, replacing telnetd with the one shipped with 1.1.5.1 fixes > this problem. This is because the TELNET in 1.x had a broken LINEMODE. 2.x has a working LINEMODE, but this is sometimes not what programs expect. To wit: LINEMODE provides for remote interpretation of control characters, so that keyboard `commands' like `interrupt', `are-you-there', and others can be sent out-of-band. (Actually, this is a simplification.) This has the beneficial effect that `interrupt', `are-you-there', `abort output' and such actually work no matter how much data is buffered in the socket layer. LINEMODE also provides for local line-at-a-time input with editing controls defined by the remote host, in the same way as these `commands' are defined. This can be enabled independently of the `command' processing. The `telnet' daemon and client cooperate to provide LINEMODE with line-at-a-time input when the remote TTY's input mode is ICANON|ISIG. When the input mode is ISIG without ICANON, LINEMODE without the line-oriented input is used. Some programs attempt to ``hijack'' plain ISIG mode in an attempt to get the system to do more of their work for them. For example, Emacs in certain input modes will program the TTY driver to disable all of the special characters except VINTR which is set to control-G. Then, Emacs gets a SIGINT whenever the user types control-G. When Emacs needs to actually read a sequence containing the control-G character (because, for example, the user invoked quoted-insert [C-q]), it knows to interpret the following SIGINT as if the user had actually typed a control-G. Now you see the problem: when running through TELNET, the signals that programs expect to get can be delivered out-of-order with respect to the input, which can cause them to become confused or malfunction entirely, depending on how detailed their model of how ttys work actually is. This is particularly true in the case of ICANON|ISIG mode, which /bin/csh uses. In Frank's case, the end-of-file ``signal'' (actually a zero-length-read) is not delivered until after the line he is composing (including its end-of-line character) has been forwarded to the server, so `csh' never sees the incomplete line he is trying to complete. The TELNET daemon interprets the unsetting of the EXTPROC bit in the termios state (e.g., by `stty -extproc') as a request to disable LINEMODE, which is why this causes such applications to work properly. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick