MQUINN@UTCVM.BITNET (05/12/91)
On Sat, 11 May 91 08:47:46 EDT <Tabakal@UB.CC.UMICH.EDU> said: >As usual, people post before checking with the source... > >The GIF files at apple2.archive are all Binscii files. That's why they >end in .bsq (binscii/shrinkit). In fact, almost all of the files are >in Binscii format (less than 10% are not). I move that we start using .BNS for 'binscii/shrinkit' files considering that .BSQ was a popular subfix for Binary II squeezed files. It's a real pain the behind trying to decifer all the compression formats and having two different formats using the same subfix really screws things up. I know there aren't alot of binary II squeezed files on FTP sites (if any) but there are some floating around on local BBSs. Anyone second this? Anyone think I'm nuts? (maybe I souldn't have asked that) ---------------------------------------- BITNET-- mquinn@utcvm <------------send files here pro-line-- mquinn@pro-gsplus.cts.com
WAXMONRW@SNYBUFVA.BITNET (05/12/91)
Todd Bakal said: >As usual, people post before checking with the source... T>The GIF files at apple2.archive are all Binscii files. That's why they en>end in .bsq (binscii/shrinkit). In fact, almost all of the files are in> Binscii format (less than 10% are not). >Binscii files must be retrieved in ASCII format, not Image/Binary. If >you use the latter you will get garbage, regardless of where you get >them. Sorry, but that is not true. For those of us who obtain your .bsc files via Bitftp@pucc, they must be retrieved as binary and then they must be "fixed". There are least two of us on the net who must request those files as binary. This is also true of bsc files from tybalt at caltech. Ray Waxmonsky (waxmonrw@snybufva) Dept. of Geography Buffalo State College
daveh@ccwf.cc.utexas.edu (Dave Huang) (05/12/91)
In article <9105111730.AA08829@apple.com> MQUINN@UTCVM.BITNET writes: >I move that we start using .BNS for 'binscii/shrinkit' files considering >that .BSQ was a popular subfix for Binary II squeezed files. It's a real I thought that Binary II squeezed files were .BQY. Anyways, many people are used to .BSQ, and switching to something else might cause some confusion :) >---------------------------------------- > BITNET-- mquinn@utcvm <------------send files here > pro-line-- mquinn@pro-gsplus.cts.com -- David Huang | Internet: daveh@ccwf.cc.utexas.edu | "Help! My ganglion is UUCP: ...!ut-emx!ccwf.cc.utexas.edu!daveh | stuck in some chewing gum!" America Online: DrWho29 |
MQUINN@UTCVM.BITNET (05/12/91)
On Sun, 12 May 91 02:48:54 GMT Dave Huang said: > >I thought that Binary II squeezed files were .BQY. Anyways, many >people are used to .BSQ, and switching to something else might cause >some confusion :) You're absolutely right about the .bqy extension. Thanks for pointing that out I feel like a complete IDIOT now :-\ >David Huang | >Internet: daveh@ccwf.cc.utexas.edu | "Help! My ganglion is >UUCP: ...!ut-emx!ccwf.cc.utexas.edu!daveh | stuck in some chewing gum!" >America Online: DrWho29 | ---------------------------------------- BITNET-- mquinn@utcvm <------------send files here pro-line-- mquinn@pro-gsplus.cts.com
alfter@nevada.edu (SCOTT ALFTER) (05/13/91)
In article <9105111730.AA08829@apple.com> MQUINN@UTCVM.BITNET writes: >I move that we start using .BNS for 'binscii/shrinkit' files considering >that .BSQ was a popular subfix for Binary II squeezed files. It's a real I thought .BQY was the standard suffix for squeezed Binary II stuff. What might be simpler, though--not to mention more portable--might be to replace BinSCII with uuencode and uudecode, now that someone has seen fit to port those utilities to the II. On the other hand, BinSCII is easier to use with the way it splits large files and its ability to skip junk that it can't read. (Unless someone wants to fix uuen/decode somehow to behave the same way--but that isn't likely to happen.) Scott Alfter-----------------------------_/_---------------------------- Call the Skunk Works BBS (702) 896-2676 / v \ 6 PM-6 AM PT 300/1200/2400 Internet: alfter@uns-helios.nevada.edu ( ( Apple II: GEnie: S.ALFTER \_^_/ the power to be your best!
lucifer@world.std.com (Kevin S Green) (05/14/91)
In article <1991May12.190918.6252@nevada.edu> alfter@nevada.edu (SCOTT ALFTER) writes: |What might be simpler, though--not to mention more portable--might be |to replace BinSCII with uuencode and uudecode, now that someone has |seen fit to port those utilities to the II. On the other hand, |BinSCII is easier to use with the way it splits large files and its |ability to skip junk that it can't read. (Unless someone wants to fix |uuen/decode somehow to behave the same way--but that isn't likely to |happen.) Now that's an excellent idea! There are many implementations of uuencode around including source code for some. Some of these implementations are extremely robust. Once I've finished teaching myself C, I plan to try my hand at writing a uuencode utility so I cast my vote that we move to uuencode. -- Kevin S. Green / lucifer@world.std.com / {xylogics;uunet}!world!lucifer
daveh@ccwf.cc.utexas.edu (Dave Huang) (05/14/91)
In article <1991May13.202755.18108@world.std.com> lucifer@world.std.com (Kevin S Green) writes: >Now that's an excellent idea! There are many implementations of >uuencode around including source code for some. Some of these >implementations are extremely robust. Once I've finished teaching >myself C, I plan to try my hand at writing a uuencode utility so >I cast my vote that we move to uuencode. 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. >-- >Kevin S. Green / lucifer@world.std.com / {xylogics;uunet}!world!lucifer -- David Huang | Internet: daveh@ccwf.cc.utexas.edu | "Help! My ganglion is UUCP: ...!ut-emx!ccwf.cc.utexas.edu!daveh | stuck in some chewing gum!" America Online: DrWho29 |
unknown@ucscb.UCSC.EDU (The Unknown User) (05/14/91)
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 /
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (05/14/91)
unknown@ucscb.UCSC.EDU (The Unknown User) writes: > Honestly, I think "we" (i.e. the programmers of the original >Binscii and any variants) should make a few small changes if necessary: > 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?? Shh! Todd Whitesel toddpw @ tybalt.caltech.edu
unknown@ucscb.UCSC.EDU (The Unknown User) (05/14/91)
In article <1991May14.033930.26612@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: .unknown@ucscb.UCSC.EDU (The Unknown User) writes: .> Honestly, I think "we" (i.e. the programmers of the original .>Binscii and any variants) should make a few small changes if necessary: .> 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?? .Shh! That's very un-Stallman-esque of you. Besides, getting the rest of the world to use something that came out of the supposedly inferior "Apple II" world would be cool. -- /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 /
ART100@psuvm.psu.edu (Andy Tefft) (05/15/91)
I agree. Binscii was written for a reason, and it is better than uuencode in a lot of ways (especially since now there are C programs to encode and decode binscii files. These could probably be combined by anyone with any useful C knowledge). I went and wrote uuencode for my Apple because I wanted to have it, but I certainly prefer binscii!