Path: cs.tu-berlin.de!fu-berlin.de!zib-berlin.de!Germany.EU.net!EU.net!Belgium.EU.net!idefix.CS.kuleuven.ac.be!chaos.kulnet.kuleuven.ac.be!usenet From: Not configured (change c:/user/winvn/winvn.ini) (Not configured (change c:/user/winvn/winvn.ini)) X-Newsreader: WinVN 0.92.6+Well, what can one expect from a software with version number "0.92.6+"? Sigh. Software that makes its user look like a fool is IMHO a serious problem. Of course, Ron Newman saw the posting and commented
That's got to be the illegalest From: line I've seen all year.(in case you don't know it, see Ron's good netkeeping seal of approval proposal.)
(27.04.95) The problem seems to be endemic with this piece of software. Today I saw a posting to a german newsgroup with the following header:
Path: cs.tu-berlin.de!fu-berlin.de!news.dfn.de!xlink.net!sbusol.rz.uni-sb.de!sbusol.rz.uni-sb.de!usenet From: Mailadresse (Vorname Nachname) Organization: Institut X-Newsreader: WinVN 0.91.4So the horrible "defaults" are even internationalized!
tail -10000 logfile > last10kshould do it, right? Wrong. Witness these interactions:
mfx@lenin % tail -100 /home/www/log/access_log | wc 100 1000 8867 mfx@lenin % tail -1000 /home/www/log/access_log | wc 371 3707 32768 mfx@lenin % tail -10000 /home/www/log/access_log | wc 371 3707 32768While it is nice to see that "tail" is efficiently coded and needs only 32k of memory for its internal buffer, that is small consolation for me. The whole idea of combining small tools to create bigger ones goes down the drain when each tool has its own undocumented restrictions creeping in and silently modifying the results.
Oh yeah, documentation: the man page for tail(1) mentions
BUGS Data for a tail relative to the end of the file is stored in a buffer, and thus is limited in size.Nice to know that there is a limit. How large is it? Enough to keep, say, 40 lines? Or 100? We don't know. As it is, this tool is theoretically unusable if all you have is its documentation, and practically unusuable if you want to use it in a context where you can't guarantee that you'll need <32k space.
Hey, adding one lousy switch -B<buffersize in K> would have removed the whole problem, without even a change in the basic mechanism of the program! But no, hard-coding the limit is the way to go. (Of course, using backwards-fseek, when possible, would have been even better, removing the need for a buffer in at last some cases.)
Built-in fixed sizes are a known problem of many programs: witness lex, yacc, and TeX. At least they give errors, and you can parameterize lex and re-compile TeX. But you often don't have the sources for yacc, so that a re-engineering of the grammar is the only way to go.
If you have problems accessing links on this page, you may have a browser that doesn't know about "base" tags. The correct address of this page is "http://mfx.dasburo.com/t/index.html"; if your browser displays it as "http://mfx.dasburo.com/trash.html", it is broken. (I stumbled across this when i saw that 7 people had tried to access a non-existent "~mfx/etc.html" page (instead of the very existent "~mfx/t/etc.html"). A systematic search of the last month's log revealed 238 accesses to my pages that ended in a '404 Not Found' responses, nearly all of them to /w/ or /t/ pages, with the redirection missing. What crappy web browser is responsible for this? (Of course, there may exist a monstrous mis-link somewhere in my pages. In this case, please tell me! Why are web 'surfers' so silent? On 238 occasions, someone out there thought "shit! what's wrong with this link?", and none mailed me a note about it!)
On 01.04.95, I made all links on this page absolute, to remove the probable cause of the problem. Since no-one who encountered the problem since i wrote the preceding note (accesses from a dozen sites) sent me a bug report, I still don't know under what conditions it occured! Sigh.
(13.04.95) I found the first culprit: Sun's ultra-modern, just now pre-released HotJava (formerly known as WebRunner) ignores <base> tags. No reaction to my bug report yet.