Path: utzoo!attcan!uunet!ginosko!uakari.primate.wisc.edu!ames!uhccux!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.sources.d
Subject: Re: An idea for safer and portable unshar-ing
Message-ID: <2270@munnari.oz.au>
Date: 2 Oct 89 10:12:09 GMT
References: <1989Sep30.171114.12550@chance.UUCP> <8910020054.AA08811@cscwam.UMD.EDU>
Sender: news@cs.mu.oz.au
Lines: 33

In article <8910020054.AA08811@cscwam.UMD.EDU>, djm@wam.UMD.EDU writes:
> This suggestion seems to be moving in the direction of making archives
> that plain old /bin/sh can't unpack at all.  Perhaps it's not a bad
> idea.  An easier to parse, more standardized pure-ASCII archiving
> format than a shell archive would certainly be more appropriate for
> Amiga, MS-DOS, VMS, etc. postings, and would allow the packing and
> unpacking programs more versatility, security and control on Unix
> systems as well.

Let's not forget why we use sharchives in the first place.
The point was to have a format for distributing sources which could
be used by people who HAVEN'T got any specialised "unshar".  If I am
away from the net for a couple of months and find when I get back that
all the sources are in some new format that I can't process, I am not
going to be very happy.  And saying that something is held on an
archive somewhere is not very helpful either; lots of people have no
FTP access.

It would be ok to go over to a new format IF each of the source groups
that used it posted a fresh copy of the decoding program every month,
along with the index for the previous month.

MS-DOS people can get a shell for a small sum.  VMS people can get
DEC/Shell; and if they haven't got it, you should remember that a posting
in C is useless to many VMS sites anyway.

On the other hand, if you're interested in "more standardised" stuff,
don't forget that ASCII is (a) a *national* standard, not an international
one, and (b) superceded by the ISO 8859 family, and (c) a pain for BITNET
mail links.  Your new format should let an MS-DOS-using donor mail text
containing e-acute and other such characters to a MAC-using recipient
with no harm resulting from an intermediate passage through EBCDIC.  Get
_that_ right first, and then worry about shar.