jac@paul.rutgers.edu (Jonathan A. Chandross) (09/06/90)
Posting-number: Volume 1, Administrivia: 6 More comments on the packaging of archives. -------------------------------------------------------------------------------- From: fadden@cory.berkeley.edu (Andy McFadden) Would probably be wise to make it similar to "shar", since shar extracters exist naturally under UNIX, and source is available for //gs unshar (I don't think anybody has ported it to the //e yet... the //gs port was by me from an Amiga program). apack/aunpack do what is required, but not all that is possible. I think it boils down to existing standards vs creating a new standard. For "shar", the version I have has options to automatically restrict shar files to < 60K (with options to either split the source files or just make a new file). Also, it can be unpacked on many different systems w/o requiring an additional special program. It should be relatively simple to modify "apack" to support "shar" format; it seems impractical to post things using "shar" sometimes and "apack" at others. [ While a useful utility, shar is probably overkill for what we need. We need the following functionality of shar: - package up source in chunks (at least the version Andy talks about; others don't always do this) - pack/unpack files - when unpacking, check sizes As far as the first goes, I will (eventually) write a program to package things up in < 60 K chunks. It will be a separate program and will simply produce a list of files to go in each part of a multi-part posting. This list will be fed to apack (or something similar). The third can be served by a checksum program to verify that all files were unpacked with the appropriate count. This will be a simple program. A file containing checksums will be included with the distribution. All you do is tell the checksum program to verify the checksum file's checksums against the distribution. (And, of course, the checksum file will have a checksum on it.) In general, we need a program that runs on a //+, //e, //c, and a //gs. I suspect that the amiga shar will be too big for anything except a gs. And extending apack/aunpack would probably cause the same problem. I don't seen any problem with posting Apple // source in apack format and Unix-only source in either shar format or apack format. For consistency, apack is fine by me for Unix-only. ] -------------------------------------------------------------------------------- From: lwv27%CAS@pucc.princeton.edu, Larry W. Virden Re: writing apack/unpack in Applesoft. > someone on comp.sys.apple2 was just raving about MD-BASIC - let them take > a crack at it! Morgan claims it makes Applesoft almost as easy as C... [Since MD-BASIC -- as I understand it -- translates into Applesoft, this would be a workable solution. But, then again, I don't think translating apack/aunpack directly into Applesoft would be terribly hard.] -------------------------------------------------------------------------------- To get something posted to comp.sources.apple2, send it to: Internet: jac@paul.rutgers.edu UUCP: rutgers!paul.rutgers.edu!jac Jonathan A. Chandross Internet: jac@paul.rutgers.edu UUCP: rutgers!paul.rutgers.edu!jac