Unnecessary tar-compress-uuencodes

[D'Arcy J.M. Cain]

In article <3124 at psueea.UUCP> kirkenda at eecs.UUCP (Steve Kirkendall) writes:
>Here's an idea: Lets compromise!  Come up with a format that really works!
>
Good idea bu I think it involves fixing things in different places rather
than trying to come up with a new format.  No one is going to switch to
a completely new format.

>1) The archive should be plain-text.  That is, each text file in the archive
>   should be easy to locate within the archive, and it should be readable
>   without the need to extract it.
Already covered by shar

>2) The format would only be used to combine several text files into a single
>   text file.  If you really must include a non-text file, then uuencode
>   that one file.
Shar again

>3) Archives should begin with a table of all printable ASCII characters,
>   so we can tell when transliteration has gone awry.
Shar can be modified to put something in comments.

>4) The archive program should split long lines when the archive is created,
>   and rejoin them during extraction.
Modify shar to do this.  All it would take is to put a '\' if the line goes
beyond a certain point and continue on the next line.  The shell will put it
back together properly.

>5) Tabs should be expanded to spaces.  The extraction program should convert
>   groups of spaces back into tabs.
Bad idea.  What if the original file had no tabs in it?  The extraction program
would change multiple spaces to tabs thus doing what you are trying to avoid.

>6) The program that creates the archive should give a warning message when
>   a file's whitespace is likely to be reformated.  For example, spaces at
>   the end of a line are a no-no.
Could be added to shar if desired.

>7) The extraction program should be clever enough to ignore news headers and
>   other introductory text, just for the sake of convenience.
Nice addition but it is also nice to be able to use the shell which everyone
has.  Non Unix boxes that emulate the work of the shell with an extraction
tool can add this if desired and a preprocessor can be added to Unix.  I
don't see this as being a major 'wannit' though.

>8) It should be possible to embed one archive inside another.  This ability
>   probably wouldn't see much use, but lack of the ability could sure be a
>   nasty surprise to somebody.  "What?  You mean it only works on *some*
>   text files?"
I have never tried it but I don't believe this is a problem with shar.

>9) Should we use trigraphs for some of the more troublesome ASCII characters?
>   The extraction utility could convert them back into real characters.
Again shar can be banged on a little to handle this.  Simply change the
sed command that it generates to translate trigraphs to the proper character.
Then shar can convert all troublesome characters and it will be converted back
when the script is run.  Create a temporary sed script at the start of the
script and use it for all the files.  That way sites that have problems
with some characters can modify the script before running it so that they
stay as trigraphs.  This has the added benefit of doing automatic trigraph
conversion at sites that require it.  Is there a trigraph for tabs?  If not
just invent one and you can handle the tab problem as well.

>Did I miss anything?  Did I get anything wrong?  Does anybody know of an
>existing format that comes close to these specs?
shar. :-)

if people think there are some good ideas here I am willing to do some
hacking on shar/unshar to implement some of this stuff.

-- 
D'Arcy J.M. Cain (darcy at druid)     |   Government:
D'Arcy Cain Consulting             |   Organized crime with an attitude
West Hill, Ontario, Canada         |
(416) 281-6094                     |