Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!lll-lcc!ames!think!husc6!seismo!munnari!murdu!u3369429
From: u3369429@murdu.UUCP
Newsgroups: comp.os.vms
Subject: Re: shar for VMS
Message-ID: <1263@murdu.OZ>
Date: Sun, 14-Jun-87 23:42:50 EDT
Article-I.D.: murdu.1263
Posted: Sun Jun 14 23:42:50 1987
Date-Received: Wed, 17-Jun-87 01:46:44 EDT
References: <8706131259.AA08840@ucbvax.Berkeley.EDU>
Followup-To: comp.os.vms
Distribution: world
Organization: I.A.E.S.R., Melbourne University
Lines: 41

In article <8706131259.AA08840@ucbvax.Berkeley.EDU> JOHN@UKANVAX.BITNET writes:
>[ ... Modesty clearly dictates that the praise of the few should not be
>      quoted to the many]
>Is this shar compatible with UNIX shar?

No. But the idea is the same.
I know next to nothing about unix, but I think shar'ed files are created
with a script which packages the sources in way that they will survive
most mailing agents, and un-pack themselves for any recipient (under a
{any consonant]un{any vowel}x system, that is).

VMS_SHAR follows the same idea: it will package source files into a self-
unpacking VMS procedure.

By the way, I've also got a unix shar to run under VMS and AmigaDOS (which
coincidentally are the two systems I know more than nothing about).
>
>I have a few observations that might help the robustness of shar. I think there
>might be a problem with line wrapping.  If the sent file has a long line, the
>line might be wrapped while being kicked around the net. In fact, even if the
>sender has been careful to keep things short, the extra "X" in front of each
>line might make the lines that used to barely fit become too long.  Also, what
>about trailing spaces?  Some systems strip them, and some systems pad all lines
>to 80 characters.

As mentioned above, I just followed the idea of unix shar which doesn't
care much about lines being longer than 80 characters or trailing spaces.

I didn't experience any troubles in this respect with mail/news items.
Long lines were always intact, and source code should not be sensitive to
trailing spaces/tabs whatever.
However, leading spaces/tabs seemed to be eaten. That's why the leading X
is used.

Speaking of which, does anybody out there know a method to use EDIT from
a procedure to a) insert an X as the first character in each line and
b) to remove it?

Michael Bednarek (u3369429@{murdu.oz.au | xvax.dn.mu.oz.au})

"POST NO BILLS!"