Date: Fri, 12 Apr 1996 00:01:19 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-hackers@freebsd.org (FreeBSD hackers) Cc: chuck@bus.net (Chuck O'Donnell) Subject: Re: Need help with possible fbsd bug Message-ID: <199604112201.AAA06483@uriah.heep.sax.de> In-Reply-To: <Pine.BSF.3.91.960410184210.3535B-100000@edna.bus.net> from "Chuck O'Donnell" at Apr 10, 96 06:55:34 pm
next in thread | previous in thread | raw e-mail | index | archive | help
As Chuck O'Donnell wrote:
While there's admittedly some bogosity with the pty handling (simple
evidence: run ``cat < /dev/ttypf'' in one window, and say ``echo hello
> /dev/ptypf'' in another one -- nothing will show up in the first
window), a couple of nits:
> so jove is being told that the write was successful, but 0
> bytes were written! Jove only checks whether the write was
> successful, and doesn't pay attention to the length reported by
> write. Jove will not retry this write, although that would be
> reasonable.
I would consider this an error:
NAME
write, writev - write output
...
When using non-blocking I/O on objects such as sockets that are subject
to flow control, write() and writev() may write fewer bytes than request-
ed; the return value must be noted, and the remainder of the operation
should be retried when possible.
Now it's arguable whether a pty counts as ``subject to flow control'',
but a short write is IMHO not an exception.
> 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?
--
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?199604112201.AAA06483>