Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!agate!darkstar!ucscb.UCSC.EDU!unknown From: unknown@ucscb.UCSC.EDU (The Unknown User) Newsgroups: comp.sys.apple2 Subject: Re: GIF pics at apple2.archive.umich.edu Message-ID: <15755@darkstar.ucsc.edu> Date: 14 May 91 02:17:08 GMT References: <1991May12.190918.6252@nevada.edu> <1991May13.202755.18108@world.std.com> <48958@ut-emx.uucp> Sender: usenet@darkstar.ucsc.edu Organization: University of California, Santa Cruz; Open Access Computing Lines: 30 In article <48958@ut-emx.uucp> daveh@ccwf.cc.utexas.edu (Dave Huang) writes: >Personally, I don't like uuencode. I haven't seen all of the >implementations, but the ones that I have seen are almost exactly like >the "real" Unix one, which isn't that great. Combining multiple part >uuencode files is a pain. With BinSCII, you can just stick them >together and everything works fine. With uuencode, you have to delete >all header and trailer lines, then stick the files together. Also, >uuencode doesn't have any checksums, unlike BinSCII. I don't like uuencode/uudecode either. I think it's strange that people are suggesting we all now jump to uuencode since it's available for for all //s now.. Honestly, I think "we" (i.e. the programmers of the original Binscii and any variants) should make a few small changes if necessary: (1) Make binscii work (if it does not now) on filetype-less file systems, such as UNIX and MSDOS. (That is be able to MAKE binscii files on those systems and not just decode them) After that change is made, if needed, binscii should be plopped around on all applicable newsgroups (comp.binaries.unix, comp.binaries.ibm.pc, comp.binaries.amiga, etc) as a BETTER replacement for uuencode/uudecode. Why not start a revolution?? -- /unknown@ucscb.ucsc.edu Apple IIGS Forever! unknown@cats.ucsc.edu\ |WANT to help get ULTIMA VI //e or GS written?-mail me. CHEAP CD info-mail me.| \ It's a Late Night World.... Of Love /