John Summerfield wrote:
> [EMAIL PROTECTED] ~]$ yes stuff | head -300 | cat -n | (head -2;tail -2)
>      1  stuff
>      2  stuff
> [EMAIL PROTECTED] ~]$ 
> 
> I presume this arises because head's reading ahead (if not head, then
> glibc on head's behalf), and when head's printed enough lines it simply
> closes its files (or maybe just exit()s.

yep.

> I don't see when this behaviour might actually be desired. I'd like to
> see its behaviour changed so that head consumes no more lines than it
> will report. (I note the man page is silent on what should happen, no
> surprise there).

It works as you expect only for seekable (rewindable) file descriptors.

> If you think that the current unpredictable behaviour is sometimes
> desirable, then could we please have something, maybe --nobuffer, to
> turn it off?

Have a look at the "stdio input buffering problems" here:
http://www.pixelbeat.org/programming/stdio_buffering/

Note the referenced patch on that page will have no affect
with head, as it doesn't use stdio to read data.

Pádraig.


_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Reply via email to