UNIX compress (12 or 13 bit) APW C port by Andy McFadden (fadden@cory.berkeley.edu) Version 1.1 December 1989 ***** How to use: compress [-dcvfV] [-b maxbits] [file ...] -d: If given, decompression is done instead -c: Write output on stdout, don't remove original. -b: Parameter limits the max number of bits/code [12 or 13] -f: Forces output file to be generated, even if one already exists, and even if no space is saved by compressing. If -f is not used, the output file will not be overwritten if it exists. -v: Write compression statistics. -V: Print version info. file..: Files to be compressed. If none specified, stdin is used. Output to file.Z (with same attributes as original), or stdout (if stdin is used as input). Does not replace original file if no compression is achiveved. Filenames must be short enough to concatenate the ".Z" suffix. To uncompress a file, the best way is to put alias uncompress compress -d in your login file. Then just use uncompress with the above options. Note that the maximum for this version is ** 13 bits ** . If you use the compress command normally under UNIX, you will make a compressed file which may use 16 bit codes. This port CANNOT uncompress such a file, so make sure you do something like % compress -b13 file1 file2 ... when you are compressing the files initially. ***** Benchmarks / statistics: (note these were made with a 1K I/O buffer; see comments below) File Storage Compress Uncompress Size ------------------------------------------------------------------------------ Moria GS hard drive 870/1024 sec 345/330 sec 66% / 64% of original. (577K) compress.c 3.5" drive 55 / 69 sec 38 / 37 sec 47% / 41% of original. (45K) hard drive 46 / 60 sec 28 / 30 sec /ram5 41 / 54 sec 24 / 24 sec The double entries correspond to 12 and 13-bit compress. 13-bit compress generally requires slightly more time to compress, but about the same (or even LESS in the case of MoriaGS) to uncompress. So it is probably to your advantage to use 13-bit codes. By way of comparison, ShrinkIt v2.1 takes about two minutes to compress Moria GS, with slightly better compression. It takes about 10 seconds to compress "compress.c"; the resulting file is 49% of the original. Generally speaking, ShrinkIt compresses binary or sparse files better than UNIX compress can. However, it is difficult to match the crunching power for text files. It should be painfully obvious from the few statistics here that disk speed plays a large role in the time required. After Larry Virden pointed out the virtues of setvbuf(), I boosted the buffer size to 8K. The time to compress and uncompress "compress.c" on a 3.5" drive was reduced by six and three seconds, respectively. ***** Notes: - This will require about 125K free memory to run. - The executable file is NOT compacted. When I ran compact on it, no errors were reported. However, the program crashed when I ran it. I tried this several times, all to no avail. Apparently this is due to the increased array sizes for 13-bit compress; there were no problems compacting a 12-bit only version (obtainable by setting USERMEM to 65000 in the first few lines of the program). Using static arrays instead of global automatic arrays didn't help (it still crashed, in more or less the same bank 0 location). - When uncompressing, either don't type the last .Z or type ".Z", not ".z". Under UNIX, ".z" is a different kind of file, and some parts of compress do distinguish case. - Compressing a file to stdout will probably be a mistake, since I believe that will convert linefeeds (hex 0a) to carriage returns (hex 0d). However, uncompressing a text file to a file works fine. Uncompressing a text file to the screen has the usual APW one-line weirdness. - This version does not properly support wildcards, although it does correctly handle ".." and device numbers. Things generally work the way you would expect them to, except for '=' and '?'. - The UNIX version prompts before overwriting; APW (apparently) does not allow reading from stderr, which is what compress wants to do, so I just made it not overwrite the file unless the -f option is used. - If you compress a file on UNIX and try to download it, it may grow in size because some transfer programs/protocols append null characters to the ends of files. Unfortunately this may cause compress to become confused... the best solution is probably to encapsulate it with something like NuLib (archive w/o compression) and then use ShrinkIt to extract the compressed file (extract uncompressed; works pretty fast). This will preserve the original EOF. - This won't work on subdirectories or extended files.