Unnecessary tar-compress-uuencodes

[Bengt Larsson]

In article <24445 at estelle.udel.EDU> new at ee.udel.edu (Darren New) writes:

>Other than that, the new shar format looks good.
>I would suggest making restrictions on the characters that
>can appear in filenames (like 14 chars or less, no spaces,
>colons, backslashes, [, ], only one period, no semicolons,
>and so on).  These could be enforced by default in the
>packer and turned off only after dire warnings.

Hmmm, this might be useful. I think a warning would do: "Warning:
non-portable filename, more than 14 chars ("some-long-file-name")".

It seems psychologically right. Nobody likes to be given a lot of
warnings, even if the program accepts the input.

>Incidentally, why Unix octal protection bits?  Why not
>  RWED (for read, write, execute, delete) 

Well, I borrowed them from "uuencode", that's why. The format
is primarily Unix-based, and it shows.

I'm not sure it was such a good idea with protection bits, though.
Maybe they don't belong there (I may not want the expanded files to
be publicly readable, for example).

>or some other non-Unix semantics? If it's going to a
>Unix machine, a shell script could be put in the archive 
>to properly set the protections. If you need particular
>UNIX protections, you probably also need particular owners
>and groups and such information would be nice to know for
>those not running under UNIX.    -- Darren

I don't think it's common to use owners and groups and such when
unpacking a (text) archive. I just thought it might be useful to
be able to make a file executable (like the "Configure" file in 
Larry Walls programs). That's mainly why I included the protection bits.

Bengt Larsson.
-- 
Bengt Larsson - Dep. of Math. Statistics, Lund University, Sweden
Internet: bengtl at maths.lth.se             SUNET:    TYCHE::BENGT_L