Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!mdf
From: mdf@tut.cis.ohio-state.edu (Mark D. Freeman)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: Sez, self-extracting zoo system 2.30
Message-ID: <21048@tut.cis.ohio-state.edu>
Date: 31 Aug 88 01:18:19 GMT
References: <3796@bsu-cs.UUCP> <20948@tut.cis.ohio-state.edu> <3806@bsu-cs.UUCP>
Reply-To: mdf@tut.cis.osu-state.edu (Mark D. Freeman)
Organization: CompuServe; Columbus, OH. (personal guest account) at Ohio State U.)
Lines: 66

In <3806@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>In article <20948@tut.cis.ohio-state.edu> mdf@tut.cis.osu-state.edu (Mark D.
>Freeman) writes [about sez 2.30]:
>
>>Can you use some command line parameter to just list what is in the
>>self-extracting zoo archive?  
>
>No, sez is too simple for that.  All that the self-extracting
>archive does is extract itself.

Not a major problem.

>>It seemed to want to
>>extract everything to the current directory, even though the .zoo file
>>that I fed zoo had full pathnames in it.
>
>Sez is too simple for this too.  Everything is extracted into the
>current directory.

We were looking into using self-extracting zoo archives as a means of
software distribution, which would get around having to put a copy of
zoo on every disk.

Without the ability to extract the full pathnames, we might as well use
self-extracting PKARCs.  I had hoped to switch everything we do over to
zoo files.

>Now let's examine why.
>
>First:  Self-extracting archives should not be too big.  The overhead
>is quite low now; you can have a bunch of self-extracting files on a
>disk and they don't take up much more space than just having them as
>zoo archives.

Agreed.

>Second, consider why you would use a self-extracting archive:  for
>simplicity.  Just tell the user "run this program'"

Exactly!  Not "run this program, then run this batch file which will
create all the directories and copy the files where they belong and
then delete the originals".

>But the question is still open.  Would you, the user, rather have a
>2492-byte overhead and just simple extraction, or would you rather have
>say a 10000 byte overhead and possibly a help screen, and be able
>to list contents and extract to a directory subtree?  

Would it really mean another 7K to add full path extraction?

>And if you chose
>the latter, what would you gain over simply distributing the zoo
>archive and the zoo archiver program, with a batch file to be executed
>by the user?

Lack of licensing problems.  We wouldn't have to put the zoo
documentation on the distribution disks, and have to possibly explain
"what the heck is zoo?" from end-users calling us for support.

Thanks for keeping an open mind.  In software development, everyone
seems to have a different "one right way" something should be done.
It's nice to talk to someone who is willing to haggle a bit.
-- 
Mark D. Freeman						  (614) 262-1418
Applications Programmer, CompuServe	      mdf@tut.cis.ohio-state.edu
[70003,4277]			      ...!att!tut.cis.ohio-state.edu!mdf
Columbus, OH		      Guest account at The Ohio State University