From owner-freebsd-hackers Thu Apr 11 23:17:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA27690 for hackers-outgoing; Thu, 11 Apr 1996 23:17:34 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA27685 for ; Thu, 11 Apr 1996 23:17:29 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id QAA31744; Fri, 12 Apr 1996 16:12:24 +1000 Date: Fri, 12 Apr 1996 16:12:24 +1000 From: Bruce Evans Message-Id: <199604120612.QAA31744@godzilla.zeta.org.au> To: chuck@bus.net, joerg_wunsch@uriah.heep.sax.de Subject: Re: fbsd pty bug Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> > 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. A short write shouldn't happen for blocking I/O (O_NONBLOCK clear). >> >> > 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? Because ICANON is set. In that case, exactly one line is returned (unless the read() buffer is too small to hold the line, when as much as fits is returned). Also, if the braindamaged limit MAX_INPUT is defined in then it is guaranteed that the maximum line length is <= MAX_INPUT, so readers should be able to guarantee reading exactly one line by using a buffer size of MAX_INPUT. FreeBSD defines MAX_INPUT as 255, although the limit is currently 1024 and may change. Bruce