From owner-freebsd-hackers Fri Apr 12 14:21:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA28798 for hackers-outgoing; Fri, 12 Apr 1996 14:21:57 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA28746 for ; Fri, 12 Apr 1996 14:21:42 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA09311; Fri, 12 Apr 1996 23:20:43 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA05345; Fri, 12 Apr 1996 23:20:42 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id WAA11283; Fri, 12 Apr 1996 22:40:02 +0200 (MET DST) From: J Wunsch Message-Id: <199604122040.WAA11283@uriah.heep.sax.de> Subject: Re: short writes to pty To: hugh@mimosa.com (D. Hugh Redelmeier) Date: Fri, 12 Apr 1996 22:39:59 +0200 (MET DST) Cc: chuck@bus.net, freebsd-hackers@freebsd.org, jovehacks@cs.toronto.edu Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199604120809.EAA02022@mimosa.com> from "D. Hugh Redelmeier" at Apr 12, 96 04:09:40 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As D. Hugh Redelmeier wrote: The bug has been fixed by Bruce Evans, and Bruce has also pointed out that my opinions were wrong. (Writes on a tty should block and not result in a short write, and reads on a tty in cooked mode should actually return at most one line per read() call.) > JOVE's pty usage is line oriented (hint: don't run vi in a JOVE > i-shell window!), so it is natural for it to simulate cooked mode. > Since JOVE does the line editing (erase and kill processing, > generating tty signals like INTR and QUIT, etc.), it is reasonable for > it to impose the line structure on its writes to the master-side of > the pty. > > I don't think that a partial write would have the right semantics in > this case. > > Much of this reasoning has been based on experimental results: these > corners are poorly documented in most UNIX systems. If you know > better, please tell me. > > | > Notice that the amount returned by the read was the length > | > requested by bash. I think that a pty should return at most a > | > line at a time, even if the read requested more. > | > | What does make you think this? Tty's are not inherently line-bound, > | so if there were more than a line available (regardles of your actual > | problem with the multiple copies here), why should a read() only > | return one line? > > This is a property of cooked mode tty input (aka canonical mode) under > UNIX. I have no idea if bash is using cooked mode. Well, i'm not sure, but don't forget that bash comes with a line- editor of its own. In order to work correctly, it will have to operate in raw mode while the line editor is enabled. It depends on the shell whether or not it detects that it is not running on a ``real tty''. (...) I've just tested it in emacs, and bash does detect there that it should not use its builtin line editor. It might also be interesting to know that emacs purposely tweaks the environment of the spawned shell: bash$ env EMACS=t TERMCAP=emacs:co#80:tc=unknown TERM=emacs ... So if you try to start a vi in this mode, it will refuse to run on the terminal type ``emacs''. :) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)