denbeste@bgsuvax.UUCP (William C. DenBesten) (06/03/88)
Please note that followups are directed to comp.sources.d In article <7985@brl-smoke.ARPA> w8sdz@brl.arpa Keith Petersen writes: > When Usenet can guarantee error-free and non-truncated transmission of clear > text files I will agree to posting clear text files. Until that day > arrives (is anyone working on it?) I will continue to post them as ARC > files in the comp.binaries.ibm.pc newsgroup. Someone else wrote, and I paraphrase: > The disadvantage is that a uuencoded file really messes up the > compression that goes on when UUCP is used to transfer news. From article <2277@rpp386.UUCP>, by jfh@rpp386.UUCP (John F. Haugh II): > the advantage of arc files is that arc includes crc's, where as shar doesn't. The solution that everyone seems to be stabbing near, but not hitting is that we need a shar-archiver that includes a crc check in it, rather than a simple character count. I have faked up a shar below that demonstrates this. There is one small problem with this idea, but it is easily solvable. There is not a standard unix utility that will do a crc. We would have to ship one around the net. Not having the crc program would not be a real hardship, as one could always unwrap a shar by creating a fake crc program and ignoring the insuing crc error warnings. #! /bin/sh # This is a shell archive echo "shar: extracting 'hello.c' (36 characters)" if test -f 'Makefile' then echo shar: "will not over-write existing file 'hello.c'" else cat << \SHAR_EOF > 'hello.c' main() { printf("Hello, World"); } SHAR_EOF if test `crc < hello.c` != 34f6 then echo "shar: CRC checksum error in 'hello.c'" fi fi exit 0 #End of shell archive