Thanks to all who replied -- you led me straight to the real problem. While testing suggestions, specifically trying to figure out why the memory indicators weren't filling up before the crash ocurred (I'd assumed it was crashing too quickly), I finally noticed what I should have picked up on much earlier: macperl wasn't doing the crashing, BBEdit was. I sincerely apologize for impugning macperl's ability to process vast amounts of text. After realizing my error I located my largest data files of this type (3MB), duplicated it four times, and fed the concatenated 15MB monster to macperl to prove its mettle. I used the Benchmark module to clock the inner loop and the print to file. 6.07 seconds later, running on a Powerbook G3 292, it was done. It barely had time to toss up the running camel cursor. Even cooler than that: the linux box I'd been using when the mac was crashing (a Pentium II 266, with 128MB RAM and Debian 2.0, running no other prominent tasks) completed processing a similarly sized file, with an identical script, in over *4 times* as long: 25.5 seconds. MacPerl rules! Meanwhile, I have some questions for Brad Hanson and the good folks at Bare Bones. -nat ***** Want to unsubscribe from this list? ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch