wcs) (05/03/89)
TAIL(1) (Directory and File Management Utilities) TAIL(1) BUGS Tails relative to the end of the file are stored in a buffer, and thus are limited in length. Various kinds of anomalous behavior may happen with character special files. WARNING The tail command will only tail the last 4096 bytes of a file regardless of its line count. Page 1 (last mod. 2/11/88) This was all very well in PDP-11 days, when you wanted a nice little utility that didn't use much memory. But now that "everybody" has virtual memory, there's no reason to retain this behavior; you can still make the initial buffer size be 4K to keep the "V7 > 4.2" people happy, and malloc more memory as needed so that tail always does what you ask it to. Has anybody written a public domain version of tail? Is this fixed in SVR4 or 4.3bsd? Is it time to write GNUtail? Thanks; Bill -- # Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs # also found at 201-271-4712 tarpon.att.com!wcs # welcome, to mars, eh, hosers! Have a brew and some donuts, eh?
faulkner@jmullins.harvard.edu (Don Faulkner) (05/03/89)
In article <378@cbnewsh.ATT.COM> wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs) writes:
tail...
Bill> WARNING
Bill> The tail command will only tail the last 4096 bytes of a
Bill> file regardless of its line count.
Bill> Is this fixed
Bill> in SVR4 or 4.3bsd? Is it time to write GNUtail?
from "trace tail -3 /etc/hosts" on sun os 4.0.1:
...
open ("/etc/hosts", 0, 07) = 0
lseek (0, 0, 1) = 0
fstat (0, 0x4540) = 0
lseek (0, -32768, 2) = 272434
read (0, "smr12.army.mil\n192.5.11.13 i".., 32769) = 32768
read (0, "", 1) = 0
...
Looks like it picks the last 32k ...
(my hosts file is 300k)
Ciao!
--
Don Faulkner
Building 1, Room 803
Harvard University, School of Public Health
665 Huntington Avenue
Boston, MA 02115
ARPA: faulkner%jmullins@harvard.harvard.edu
BITNET: faulkner@harvard
Telephone: (617) 732-2297kc@rna.UUCP (Kaare Christian) (05/03/89)
Also, fmt. I use fmt to fix up files transferred from various pc word processors, which often delimit *paragraphs* with nl, or cr-nl. fmt has a hardwired BUFSIZ (1024) character limit per line. That's not enough for many purposes. Arbitrary (short) limits should go. Yes, I can fix my copy of fmt, but in general, limits should be generous, especially those that pertain to a program's core functionality. Kaare Christian kc@rna.rockefeller.edu
edf@rocky2.rockefeller.edu (David MacKenzie) (05/04/89)
In article <378@cbnewsh.ATT.COM> wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs) writes: >Has anybody written a public domain version of tail? Is this fixed >in SVR4 or 4.3bsd? Is it time to write GNUtail? The GNU tail and head utilities have already been written, by me and Paul Rubin. They have not yet been generally distributed, but I would be happy to mail them to anyone who wants them. They have no buffer size limits. The GNU head is also much faster than the BSD one and can head in blocks or bytes as well as lines. ----- David MacKenzie Environmental Defense Fund edf@rocky2.rockefeller.edu (...rutgers!cmcl2!rocky2!edf)
guy@auspex.auspex.com (Guy Harris) (05/04/89)
>from "trace tail -3 /etc/hosts" on sun os 4.0.1: > >Looks like it picks the last 32k ... Credit where credit is due; this comes from 4.3BSD. The limit there is a fixed 32K....
bink@aplcen.apl.jhu.edu (Ubben Greg) (05/06/89)
In article <298@rocky8.rockefeller.edu> David MacKenzie writes: > The GNU tail and head utilities have already been written, by me and > Paul Rubin. They have not yet been generally distributed, but I would be > happy to mail them to anyone who wants them. They have no buffer size > limits. The GNU head is also much faster than the BSD one and can head > in blocks or bytes as well as lines. 1. Where is the best introduction to what GNU is all about, to be found, preferrably online? (Don't try to explain here, just point me...) 2. After spending many hundreds of hours working with certain commands, you really start to notice the problems the command has, and minor improvements (keeping in the spirit of the command's format) which would greatly increase its functionality. I realize they're probably already aware of and and have fixed most of these short-comings, but... do the GNU programmers welcome suggestions, and if so, how does one find out who to contact for what (in particular, for sed)? -- Greg Ubben bink@aplcen.apl.jhu.edu