HAKMEM again
Russell Bornschlegel
document. Imagine my surprise when I logged on to MIT's AI publications
FTP site to find, as promised, AIM-239.tiff.tar.gz. All five megabytes of
it. In order to actually read this document, I had to go through a mere
thirteen steps. The process seems so absurd that I have to share it with
someone.
It so happens that, while I'm used to MS-DOS primarily, I know enough
Unix to bootstrap myself: I can read and interpret man pages. So:
First: ftp the document from MIT to my net provider's host.
Second: fumble around the man pages to find the gzip/gunzip tools, and
gunzip the file to a .tiff.tar.
Third: tar -xvf to get about 100 separate tiff files. Sure enough, one
scanned image per page of the original document.
Fourth: I want the tiffs at work, where I have access to laser printers.
So, I need to Zmodem 100 files. The filenames are such that Procomm's
filename translation will mangle them badly: extensions of the form .0000,
.0001, .0002... (WHY not three digit extensions? WHY?) I'm not facile
enough with csh or perl or anything to write a simple script to rename
them; for some reason or another I thought that writing a C program to do
it was overkill (not to mention I'd have to figure out/remember how to use
a Unix-hosted compiler and linker), so I actually wrote 100 lines of mv
foo.#### foo.###. Now, that would have taken a few seconds in my "native"
editor, Brief for DOS, or in a real Unix editor, but I haven't had time to
learn to use a real Unix editor, and I'm really kind of embarrassed to say
I was using Pico. Anyway, I rename the files.
Fifth: I start a Zmodem batch, and wander away to do some real work. Come
back and find out the transfer crapped out on #73, try it again, 73 really
doesn't want to transfer, move some files around on the DOS box, yadda
yadda, get it up to #83, dies again, whatever, I still don't know what's
up, I figure the first 82 pages will hold me for a while, and I really
want to see if I can actually print them, so forget it for now.
Sixth: PKZIP them up on the DOS box, to HAKMEM.ZIP. At work, the modem
stations are for lame security reasons not on the Novell LAN, so...
Seventh: ...for some reason I use a cheap little file slicer I wrote,
rather than looking up how to get PKZIP to span a zip onto floppies, or
use backup/restore. Now I have HAKMEM.000, .001, .002.
Eighth: As Dave Barry would say, I AM NOT MAKING THIS UP. Floppy-copy and
sneakernet the files to my own machine.
Ninth: Use DOS's COPY /b to paste the chunks back together.
Tenth: PKUNZIP them again.
Eleventh: Realize I'd rather have them all have an extension of .TIF, and
want the sequence number in the base file name. Write a batch file to so
rename them. This time I'm using Brief, so it's quick. Column-block
instead of linear cut-and-paste is a necessity for me.
Twelfth: Experiment with a shell program I wrote to make Image Alchemy, a
command-line-oriented graphic file format exchanger and image processing
tool, easier to use. Discover that the TIFFs were scanned at 400 dpi.
Good thing my shell program does resizing, and even better, prints the
command line that it passes to alchemy, so having found the right options
interactively, I can then use the same options in batch on the whole set
of 100. Which I do, converting all the TIFFs directly to HP PCL at 300
dpi, which I figure will be easy to print.
Thirteenth and final: DOS COPY the PCL files to the printer port. They
really are scanned pictures of hardcopy, with the three-hole-punch holes
visible and everything. There's a little grungy bit on each page where the
LaserJet seems to have choked on the command codes or something. I wonder
if I really wanted to read a bunch of math trivia that's nearly as old as
I am anyway. Hmm. Don't I have an old OCR program that works on TIFF files
somewhere?
The beginning pages of HAKMEM warn that the contents are so obscure and
esoteric that you really have to have the hacker nature to get into the
document fully. From my experiences, I'd have to add that you need to
have some of the hacker nature simply to VIEW the document. Talk about
security through obscurity. :)
Eric Werme
>Thanks to those of you who gave me pointers to MIT AI Lab's HAKMEM
>document. Imagine my surprise when I logged on to MIT's AI publications
>FTP site to find, as promised, AIM-239.tiff.tar.gz. All five megabytes of
>it. In order to actually read this document, I had to go through a mere
>thirteen steps. The process seems so absurd that I have to share it with
>someone.
>The beginning pages of HAKMEM warn that the contents are so obscure and
>esoteric that you really have to have the hacker nature to get into the
>document fully. From my experiences, I'd have to add that you need to
>have some of the hacker nature simply to VIEW the document. Talk about
>security through obscurity. :)
Some of the best hacks are inadvertant. My compliments to the folks who
scanned HAKMEM is a fashion to teach DOS-folks something about Unix and
other lore.
BTW, If you use BRIEF, I understand that it's programming language is sort of
like TECO. You can get TECO's that run on DOS and Unix (and PDP-10s and
PDP-11s) and then you'll be all set. Frankly, I think you should have
upgraded your PC to Linux and skipped a lot of the DOS steps! :-) :-)
Oh:
>The filenames are such that Procomm's
>filename translation will mangle them badly: extensions of the form .0000,
>.0001, .0002... (WHY not three digit extensions? WHY?)
Indeed, the cccccc.ccc filename format that made so much sense on PDP-10s
when core was expensive should have been junked by MS-DOS V2. WHY wasn't
it? WHY? (And please, I *know* why CP/M went to an 8.3 format instead of
8.4, so no need to fill that in!)
Richard M. Alderson III
(Eric Werme) writes:
>Indeed, the cccccc.ccc filename format that made so much sense on PDP-10s
>when core was expensive should have been junked by MS-DOS V2. WHY wasn't
>it? WHY? (And please, I *know* why CP/M went to an 8.3 format instead of
>8.4, so no need to fill that in!)
It wasn't that core was expensive (though it was). It was the need to save as
much space as possible for data on expensive disks and small DECtapes for real
data.