Date: Thu, 20 Dec 2007 10:58:08 -0600 From: Erik Osterholm <freebsd-lists-erik@erikosterholm.org> To: Mikhail Teterin <mi+kde@aldan.algebra.com> Cc: questions@freebsd.org Subject: Re: tail does not exit Message-ID: <20071220165807.GA34089@aleph.cepheid.org> In-Reply-To: <200712201102.59565@aldan> References: <200712192322.lBJNMfps053071@aldan.algebra.com> <200712200540.11553@aldan> <20071220155336.GA31047@aleph.cepheid.org> <200712201102.59565@aldan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 20, 2007 at 11:02:59AM -0500, Mikhail Teterin wrote: > On ?????? 20 ??????? 2007, Erik Osterholm wrote: > = The same behavior happens if I use a larger file. I see no > = inconsistent behavior, nor any bugs. > > The inconsistency is in the fact, that the behavior depends on the size of the > buffer and length of the lines (not the size of the file). > > If the 10 lines, which tail tries to output initially, exceed the size of the > buffer, tail learns about awk going away immediately. If the lines are not > long enough, it does not. > > Also, I would expect a program to be notified (by SIGPIPE?) /immediately/, > when any of its output pipes are closed -- instead of waiting for it to try > to write into the pipe. But this issue is not, it seems, FreeBSD-specific... > > -mi Ah, I see. With very, very long lines, tail doesn't send the output all at once. The cutoff seems to be 65536 bytes on my system. If tail has to write more than this amount, it breaks it up into mutliple writes of a maximum of 65536 characters each. The problem is that after the first 65536 characters, awk has exited, causing the next 65536 characters which tail attempts to write to cause a SIGPIPE. It seems to be working as intended, though. When piping, you have to be aware of these issues, but I do not think that it is a bug. There must be some boundary where tail splits the output into multiple writes. If, after the first write, a \n hasn't been encountered yet, awk will consider at least some portion of the next write (up until the first \n) to be the same line, at least until it hits its own limit. I have not checked to see what this limit might be. As for SIGPIPE, that's just how the POSIX standard works. The signal is sent to the writing process when it attempts to write to a broken or closed pipe, not when the pipe has closed. If you think that this behavior is bad, you might want to contact IEEE. Erik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071220165807.GA34089>