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
> 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...
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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"