RDROYA01@ULKYVX.BITNET.UUCP (02/27/87)
[was there a line above this one?] In article comp$sys$atari$st 1288 L. J. Dickey [ljdickey@water.UUCP] writes: > Not too long ago someone posted code for "shar" that was said to compile > both on a vax and on the ST. Because I'm the one who posted shar, I guess I should be the one to defend it. > I would like to pose the question: Why use shar? > The uses of "shar" that I have seen in this group have been to bundle > several files together and do some trivial checking, such as counting > characters, and of those that I have looked at in this group, every one > has given some error report. I count that as unreliable. While it is true that shar does not contain heavy error checking (I never even use what little is there), it is also true that it was not designed to do heavy checking. I think there are real advantages to shar for transferring text files from one computer to another. I use shar, not just for transferring files across the net, but for transferring groups of files from my micro to our vax. It always seems easier to me to transfer one or two large archives than a group of small texts. (And I am talking about text, not binaries.) > Just on the surface, it looks like "uuencode" and "arc" are more useful > than "shar". I would like to hear a defense of "shar". Arc is a useful utility when you have something on the other end to dearc the file, but Arc plus uuencode will often convert text files into archives larger than the individual files which translates to longer upload time. Then there is the problem of getting a huge binary archive onto the ST and finding CRC errors in it so that it will not dearc. I ported shar to the ST because I often grab sources from mod.sources and 98 percent of those are in shar format. Usually the code has a few character transpositions. Curly braces end up with the high bits set. A few other characters get transposed also. Shar does not care about this and will still extract all the parts. I even have a small filter which changes all the characters back. > On the other hand, some people have used "arc" and "uuencode" and most of > the things I have looked at that use these programs have worked. The > "arc" program has some error checking in it, and it seems to be better > than the checking used by people here using "shar". Were I to receive an arced version of the original source, download it to the ST and run it through standard uudecode, chances are those same types of transpositions would occur (every standard uuencoded file I've decoded has been that way because our files come through an IBM along the line). Arc just dies, and there is no way to salvage any of the lost info. On our Vax, most of what I have compiled on the ST will port almost directly to the ST. In fact I often unshar and compile first on the Vax before I download source. The final argument I have in favor of shar is that it encourages the distribution of source code and lets readers see the code before copying it to their accounts. (Mail is more civilized on our system than some; we don't subscribe individually to newsgroups but extract what we want from a collective pool.) > Prof. L. J. Dickey, Faculty of Mathematics, University of Waterloo. > ljdickey@water.UUCP ljdickey%water@waterloo.CSNET > ljdickey%water%waterloo.csnet@csnet-relay.ARPA > ljdickey@water.BITNET Robert Royar, Department of English, University of Louisville rdroya01@ulkyvx.bitnet rdroya01%ulkyvx.bitnet@wiscvm.arpa