sbm@purdue.UUCP (Steven B. Munson) (01/10/86)
In article <8081@amdcad.UUCP>, jimb@amdcad.UUCP (Jim Budler) writes: > Gary Perlman posted a program for Unix and MSDOS called fpack to > mod.sources recently. This program packs text files for transmission to > micros without the benefit of sh or unshar. I hope no one is planning to use this for posting to net.sources.mac. We have packit already, and I prefer to do all the file munging and unpacking on UNIX. Once something gets downloaded to the Mac, those teeny-tiny disks make it very time-consuming to do further conversions. Steve Munson sbm@Purdue.EDU sbm@Purdue.CSNET
jimb@amdcad.UUCP (Jim Budler) (01/17/86)
In article <1113@arthur.purdue.UUCP> sbm@purdue.UUCP (Steven B. Munson) writes: >In article <8081@amdcad.UUCP>, jimb@amdcad.UUCP (Jim Budler) writes: >> Gary Perlman posted a program for Unix and MSDOS called fpack to >> mod.sources recently. This program packs text files for transmission to >> micros without the benefit of sh or unshar. > > I hope no one is planning to use this for posting to net.sources.mac. >We have packit already, and I prefer to do all the file munging and >unpacking on UNIX. Once something gets downloaded to the Mac, those >teeny-tiny disks make it very time-consuming to do further conversions. Not to be to obvious about it, but the original posting did say *text* files. Now for an example: Hack for Unix came over the net a while back, in a group of shar archives. Now how do I transport those source to the Mac? I unshar them, then I macput -u each one of them???? That's how I did it a year ago. Now if you want to write a packit compatible Unix program which can unpack and pack packit files on Unix, go ahead. Or if you want to write a /bin/sh compatible unpacker for the Mac, go ahead. Meanwhile, the next time a shar archive full of source code I want to port to my Mac comes along, I will unshar it on my Unix system, fpack the files into a smaller number of files, and macput -u those to the Mac where I can unfpack them and begin porting. ( and yes, I know about macsend *; I prefer a this.) -- Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb Compuserve: 72415,1200
bart@reed.UUCP (Bart Massey) (01/20/86)
> Now for an example: Hack for Unix came over the net a while back, in a group > of shar archives. Now how do I transport those source to the Mac? I > unshar them, then I macput -u each one of them???? That's how I did it a year > ago. > > Now if you want to write a packit compatible Unix program which can unpack > and pack packit files on Unix, go ahead. Or if you want to write a /bin/sh > compatible unpacker for the Mac, go ahead. Meanwhile, the next time a shar > archive full of source code I want to port to my Mac comes along, I will > unshar it on my Unix system, fpack the files into a smaller number of > files, and macput -u those to the Mac where I can unfpack them and begin > porting. > > Jim Budler Obviously what is desperately needed is C source for: A two-way xbin (to and from binhex format on a Unix machine) A two-way packit (to and from packit format on a Unix machine) Neither of these is non-trivial, obviously. The hacks to binx (un-xbin) a file that came over the net a while ago would be a good start on this one. The other would have to be written from scratch. Any takers? BTW, if the BinHex5.0 file format is ever universally adopted, it could solve the problem with appropriate (fairly simple) hacks to macput and macget, as it provides for a limited form of batch transfer... Bart Massey ..tektronix!reed!bart
sbm@purdue.UUCP (Steve Munson) (01/21/86)
In article <8388@amdcad.UUCP>, jimb@amdcad.UUCP (Jim Budler) writes: > ...Now how do I transport those source to the Mac? I > unshar them, then I macput -u each one of them???? Geez, I must be confused. If you know how to use the shell, you say for file in * do macput -u $file done right? The point is that unsharing on UNIX and downloading scores of files at once to the Macintosh is easy (can be done automatically). Anything that gets in the way of this process, like packit or any Macintosh file munger without a UNIX equivalent, is a hindrance. Once a large file gets to the Macintosh, it becomes much more difficult to convert further. > Now if you want to write a packit compatible Unix program which can unpack > and pack packit files on Unix, go ahead. I wish someone would, or even better yet, stop posting packitted files; use shar instead (I know, not as much data compression). > Or if you want to write a /bin/sh > compatible unpacker for the Mac, go ahead. That would be a waste of time, and, as I understand it, that is what you are doing, right? Am I missing something really obvious here? -- Steve Munson sbm@Purdue.EDU sbm@Purdue.CSNET
jimb@amdcad.UUCP (Jim Budler) (01/22/86)
In article <450@mordred.purdue.UUCP> sbm@purdue.UUCP (Steve Munson) writes: >In article <8388@amdcad.UUCP>, jimb@amdcad.UUCP (Jim Budler) writes: >> ...Now how do I transport those source to the Mac? I >> unshar them, then I macput -u each one of them???? > > Geez, I must be confused. If you know how to use the shell, you >say >... >right? The point is that unsharing on UNIX and downloading scores of >files at once to the Macintosh is easy (can be done automatically). >Anything that gets in the way of this process, like packit or any >Macintosh file munger without a UNIX equivalent, is a hindrance. Once a >large file gets to the Macintosh, it becomes much more difficult to >convert further. > >> Now if you want to write a packit compatible Unix program which can unpack >> and pack packit files on Unix, go ahead. > > I wish someone would, or even better yet, stop posting packitted >files; use shar instead (I know, not as much data compression). > >> Or if you want to write a /bin/sh >> compatible unpacker for the Mac, go ahead. > > That would be a waste of time, and, as I understand it, that is >what you are doing, right? > > Am I missing something really obvious here? I'll try one more time. There are many reasons to prefer a package over a scad of individual file transfers. 1) I may not be attempting to port the code immediately and thirty source files sitting around with relatively (outside the context of the program) incomprehensible names like 'tty.c' sitting on a disk is much less desirable than one file 'Hack.fpack'. Two years later I can browse the directory of that disk and know what that file is. 2) Using your suggestion if one of the files in the middle bombs the transfer, and I'm not attending the transfer closely, I may not know exactly what I lost. I prefer the overhead of retransmitting a large file more than once to the overhead of examining all files to determine what I lost. 3) When I'm porting code to the mac I prefer to keep the original code around in case I really blow it and want to revert. You can keep a disk with the original code on it ( I often do ) or you can keep the original archive disk ( packit of fpack ) around and just (with fpack) remove or rename the offending file and unpack again it will only unpack nonexisting files. I know, if I plan ahead and keep the file I'm modifying around with a backup name (such as file.c.00) I don't need to do this. But at some point I will decide I don't need that on the disk and throw it away. Murphy's law guarantees that I will want that file the next day. 4) I don't know if you work with only one disk or what, but I generally find unpacking packit files or fpack files on the mac to be little problem. I find sitting around the mac watching the little meter inch its way towards 100 percent to be much more painful. On your comments concerning packit, you should remember that packit is not a Unix developed program, and many of the programs that come packited originated in places where Unix is not spoken. The alternative to packit would require that a person developing or transmitting mac developed programs send them individually to Unix, and either sending a scad of posted files or sharing together. The recent 1040 files posted ( 7 of them ) would have been a much larger number of postings if packit hadn't been used. If shar had been used autoxbin wouldn't work. If you don't like it, don't use it. If someone ever posts something using it just fire up your editor on unix, search for 'fpack:!@#$%' and split the file. I use it, other people set me letters of thanks, so they use it, so as far as I'm concerned the posting was totally justified. Bye. -- Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb Compuserve: 72415,1200
jimb@amdcad.UUCP (Jim Budler) (01/22/86)
In article <8568@amdcad.UUCP> jimb@amdcad.UUCP (Jim Budler) writes: >In article <450@mordred.purdue.UUCP> sbm@purdue.UUCP (Steve Munson) writes: >>In article <8388@amdcad.UUCP>, jimb@amdcad.UUCP (Jim Budler) writes: >... >>Anything that gets in the way of this process, like packit or any >>Macintosh file munger without a UNIX equivalent, is a hindrance. Once a >>large file gets to the Macintosh, it becomes much more difficult to >>convert further. P.S. THERE is a Unix equivalent to fpack, it came first. see mod.sources. -- Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb Compuserve: 72415,1200