Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.jpl.nasa.gov (Larry Wall)
Newsgroups: comp.compression
Subject: Re: Problems running compress from perl on MS-DOS
Keywords: compress, perl, MS-DOS
Message-ID: <1991May10.000349.7678@jpl-devvax.jpl.nasa.gov>
Date: 10 May 91 00:03:49 GMT
References: <991@camco.Celestial.COM>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 33

In article <991@camco.Celestial.COM> bill@camco.Celestial.COM (Bill Campbell) writes:
: I am trying to build an archive of compressed files on an MS-DOS
: system using a perl script.  The guts are:

: 	open(ARCHIVE, "archive");
: 	binmode(ARCHIVE);
...

: This works fine on Xenix/Unix systems, but the MS-DOS version has
: one of two problems:
: 	1.	It frequently says that it is out of memory compressing
: 		from stdin.  I have recompiled compress for 12-bit
: 		compression and it does this less frequently, but it
: 		still does it.

You need to get ahold of Len Reed's mods that swap perl out to secondary
storage while running a subprocess.  compress's data structures tend
to use all of an MS-DOS machines ordinary memory.  Or get a version
of compress that uses extraordinary memory.  :-)

: 	2.	The compressed file is longer than it should be.  It
: 		appears that it might be created as a text file rather
: 		than binary when the standard output is redirected to the
: 		file.

I don't know if it's related, but you need to put a > before the
filename when you open the archive.  It might be that binmode only words
if you've opened the file for output.  That wouldn't explain compress's
problems, if that's where the problem is.  It might explain the buffer
troubles though.

Just not another MS-DOS hacker,
Larry