Date: Fri, 12 Apr 1996 22:39:59 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: hugh@mimosa.com (D. Hugh Redelmeier) Cc: chuck@bus.net, freebsd-hackers@freebsd.org, jovehacks@cs.toronto.edu Subject: Re: short writes to pty Message-ID: <199604122040.WAA11283@uriah.heep.sax.de> In-Reply-To: <199604120809.EAA02022@mimosa.com> from "D. Hugh Redelmeier" at Apr 12, 96 04:09:40 am
next in thread | previous in thread | raw e-mail | index | archive | help
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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604122040.WAA11283>