Xref: utzoo comp.sources.d:6183 comp.sources.bugs:2740
Path: utzoo!attcan!lsuc!eci386!woods
From: woods@eci386.uucp (Greg A. Woods)
Newsgroups: comp.sources.d,comp.sources.bugs
Subject: Re: problems patching trn
Keywords: trn patch shar
Message-ID: <1990Dec18.161217.15761@eci386.uucp>
Date: 18 Dec 90 16:12:17 GMT
References: <1990Dec17.070057.29084@zorch.SF-Bay.ORG>
Reply-To: woods@eci386.UUCP (Greg A. Woods)
Organization: Elegant Communications, Inc.
Lines: 40

In article <1990Dec17.070057.29084@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
> 1) I don't care how much space it saves, don't post patches as anything
> but context diffs; cutesy, non-standard methods are not the way to share
> software across a net full of people who like life as simple as
> possible; you just confuse and irritate your audience, in my case to the
> point that "rm -rf ./trn" got the archive unpacking directory.

Here, here!  I don't recall having any trouble unpacking and patching
trn, though it was irritating, and made me very paraniod to have to
compile a filter to send a diff to patch.  I almost tried to patch
from the "diff" directly, since patch is supposed to understand
ordinary diff's, if used carefully, but again paranoia won out.

On the other hand, while I've not had any trouble up to this point,
I've been scared off compiling trn with all the rumours about bugs in
the threads stuff, which is the only reason I'd compile it in the
first place.  Besides, we don't really have space for the threads file.

[ As an aside, I wish trn was simply a set of very careful patches to
rn, and as such could be applied to any version of rn.  Now, knowing a
wee bit about the innards of rn, I don't think this would be easy.... ]

>[....] Don't assume that
> the shar headers are read by your audience; I never look at them after
> the first article, the second and subsequent articles just get piped
> through unshar blindly; instructions hidden in the shar header get nuked
> by unshar and are never seen except by accident. If you have something
> to say, put it into a README file that gets unpacked and seen by ls,
> don't hide it in the shar header, which is not saved and often not seen.

Hmm... the version of unshar I use saves the header, in either
UNSHAR.HDR or [archivename].hdr, and is even very careful about
14-char filenames for us non-BSD users.  I usually save at least the
header from the first part simply because it often contains a mail
address of *somebody*.  NEVER throw away useful information!  :-)
-- 
							Greg A. Woods
woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP		ECI and UniForum Canada
+1-416-443-1734 [h]  +1-416-595-5425 [w]  VE3TCP	Toronto, Ontario CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL