xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/17/90)
When I unpacked the trn distribution with the two reposted parts, and tried to use the incredibly nonstandard patch procedure and patch1 included with it, the patch died looking for a file whose name started "mthread"; there was indeed no such file in the distribution, (at least as it unpacked for me), yet a grep through the posted articles showed it mentioned too many places to filter through and find out what was wrong. I finally pitched the trn distribution en masse, rather than have it continue to tie up a couple megabytes of disk. Does anyone have a clue to offer as to what's going on here? [N.B.: 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. 2) I found nothing in the enclosed documentation to indicate that patch1, in a format I'd never seen, was to be applied by compiling and executing the unipatch.c code and passing the result ot patch, until after I'd resorted to email to ask a friend for help. 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. ] Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
rob@mtdiablo.Concord.CA.US (Rob Boldbear) (12/18/90)
In article <1990Dec17.070057.29084@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >When I unpacked the trn distribution with the two reposted parts, and >tried to use the incredibly nonstandard patch procedure and patch1 >included with it, the patch died looking for a file whose name started >"mthread"; there was indeed no such file in the distribution, (at least >as it unpacked for me), yet a grep through the posted articles showed it >mentioned too many places to filter through and find out what was wrong. The problem was, I am told, that the so-called "repost" of part 9 was not a true repost as it included only those files that got munged in the original part 9. You needed to have both part 9's. I learned this well after I ditched the original part 9 for the repost. :-( -- Rob Bernardo Mt. Diablo Software Solutions _ / email: rob@mtdiablo.Concord.CA.US phone: (415) 827-4301 <_/_>< "Why waste time learning, when ignorance is instantaneous?" / - Hobbes (Bill Watterson)
woods@eci386.uucp (Greg A. Woods) (12/19/90)
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
jkossoy@irscscm.UUCP (Jeff Kossoy) (12/19/90)
In article <1990Dec18.065833.5520@mtdiablo.Concord.CA.US> rob@mtdiablo.Concord.CA.US (Rob Boldbear) writes: >In article <1990Dec17.070057.29084@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: {stuff deleted} > >The problem was, I am told, that the so-called "repost" of part 9 was >not a true repost as it included only those files that got munged in >the original part 9. You needed to have both part 9's. I learned >this well after I ditched the original part 9 for the repost. :-( >-- >Rob Bernardo Mt. Diablo Software Solutions _ / >email: rob@mtdiablo.Concord.CA.US phone: (415) 827-4301 <_/_>< >"Why waste time learning, when ignorance is instantaneous?" / > - Hobbes (Bill Watterson) If this is the case, is there going to be a repost of nine with all the files or is there someplace where I can get the files? Jeff -- ------------------------------------------------------------------- | These are my opinions only, and not those of my employer. | | Jeff Kossoy | -------------------------------------------------------------------