Xref: utzoo comp.sources.d:2111 comp.binaries.ibm.pc.d:240
Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mandrill!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon S. Allbery)
Newsgroups: comp.sources.d,comp.binaries.ibm.pc.d
Subject: Re: Standard for file transmission
Message-ID: <7776@ncoast.UUCP>
Date: 14 May 88 19:45:28 GMT
References: <292@cullsj.UUCP> <55@psuhcx.psu.edu> <537@csccat.UUCP> <8430@iuvax.cs.indiana.edu>
Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery)
Followup-To: comp.sources.d
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 28

As quoted from <8430@iuvax.cs.indiana.edu> by bobmon@iuvax.cs.indiana.edu (RAMontante):
+---------------
| The biggest problem I see is that many news mailers compress everything
| blindly, so that an already-compressed file gets bigger.  This would also be
| true of a sufficiently random file, although I think most executables aren't
| that random.  And this compress-and-be-damned behavior is not a strength of
| the system, it's a weakness.  (Even compress will complain if its result is
| bigger than its original; does the mailer ignore this, or are the net.gods
| lying when they claim they're shipping bigger files because of the double
| compression?)
+---------------

When compress is invoked as

		compress (file)

it complains.  When it's invoked as:

		sendbatch | compress | uux -r - oopsvax!rnews

it can't do so without compressing to a temp file while saving its input in
a second temp file, then comparing sizes and copying the smaller of the two:
wasteful of space and time.  (You can't, of course, seek backwards on a
pipe.)
-- 
	      Brandon S. Allbery, moderator of comp.sources.misc
	{well!hoptoad,uunet!marque,cbosgd,sun!mandrill}!ncoast!allbery
Delphi: ALLBERY						     MCI Mail: BALLBERY