BL> THESE SMARTARSE UNIX-WANKERS GIVE ME THE SHITS!!!!!!
 BL> First, they put a #1 cunthook header their compress doesn't
 BL> handle, they have no way to tell if the file is compressed
 BL> *inside* the file (PKZIP uses "PK" as the first two
 BL> characters), and then they use nonstandard file suffixes! Does
 BL> it mean that I have to try *every* file? 

 JT> That's the whole idea of that header. It identifies the type of
 JT> compression. The reason that header is text-based is that unix
 JT> scripts can be written very easily to read the header. It's
 JT> just like, and serves the same purpose as your "PK" string id
 JT> for zip, that you claim is better. This is the same thing.

  You miss the point. The PK header is handled by PKUNZIP, inside the
unzipper. You only have to ope nthe file once, read the header to
identify it, and then get on with unzipping. I don't care what they
use as a header, as long as the compress program handles it... which
this dopey UNI-wanker doesn't.

  This way, you have to open the file, read the header, and then write
the entire file to copy it, then close it, then open it and decompress
it having decided the correct decompressor. This is totally stupid!
You end up reading the entire file twice.

 JT> If you have a de-compresser that can't work with it, it was
 JT> probably not designed with mail in mind. 

  Neither compress 320, gzip, nor zip  handle it... they're the three
that were designed with mail in mind.

Regards,
Bob
___ Blue Wave/QWK v2.12
@EOT:

---