rminnich@udel.EDU (Ron Minnich) (07/15/87)
OK. I am cracking up. I ftp the uudecode.Z program from asc.purdue.edu. I set binary mode to do this. It looks like: -rw-r--r-- 1 rminnich 8109 uudecode -rw-r--r-- 1 rminnich 5709 uudecode.Z The uncompressed one was created from the 'shar' file in ~ftp/pub at purdue. Now i load uudecode down over kermit, after set file type binary and on the amiga it is still 8109 bytes. ADos (v1.2) starts to read it and crunches it for a few seconds, then cant load uudecode: not an object file I am going slowly nuts. Has anyone else had this problem? When i dump the file on the amiga it looks just fine. When i load C source down it gets there with no errors at all. HEEEEEEELLLLLLLP! -- Ron Minnich
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (07/16/87)
| OK. I am cracking up. I ftp the uudecode.Z program from asc.purdue.edu. | I set binary mode to do this. It looks like: | -rw-r--r-- 1 rminnich 8109 uudecode | -rw-r--r-- 1 rminnich 5709 uudecode.Z | The uncompressed one was created from the 'shar' file in ~ftp/pub | at purdue. Now I load uudecode down over kermit, after | set file type binary | and on the Amiga it is still 8109 bytes. ADos (v1.2) starts to read | it and crunches it for a few seconds, then | cant load uudecode: not an object file | HEEEEEEELLLLLLLP! The AmigaDOS segment loader is very picky about "object" files. If any garbage was present at the end of the file at purdue, or if you added any later the message will be "Unable to load XX: file is not an object module". If a file does not end with a long word aligned $000003F2 then it has probably been damaged. Use "type <name> opt h" from the CLI to check this. ($000003F2 is also know as HUNK_END) Kermit and Xmodem both have the nasty habit of adding such garbage. You need to pass the files though a program called "HunkPad" which will insert extra "HUNK_END" long words to fix things up. HunkPaded programs are also immune to future Kermit or Xmodem damage. Another program called "AutoChop" works as well, but provides no such future immunity. A working copy of uudecode can be found on FISH disk #53. Unfortunatly this ^^^^^^^^^^^^^ particular uudecode will not decode some of the files that the uudecode here on this BSD 4.3 UNIX machine will. I have not explored this, and instead uudecode on UNIX, Kermit to the Amiga and then HunkPad. Sometimes I uudecode on UNIX then use Xmodem to download to a terminal program that has "AutoChop" built in. Look for "HunkPad" in the Amiga archives at j.cc.purdue.EDU. If you find it you will be pleased to discover that it has already "immunized" itself against the type of damage that Kermit and Xmodem do. The author of HunkPad also lurks on this very net. If you still can't get a working arangement scream in that direction or mine and we'll see what can be worked out. ----------------------------- |\ /| . Ack! (NAK, EOT, SOH) {o o} . ( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce U "Success leads to stagnation; stagnation leads to failure."
stever@videovax.Tek.COM (Steven E. Rice, P.E.) (07/16/87)
In article <357@louie.udel.EDU>, Ron Minnich (rminnich@udel.EDU) writes: > OK. I am cracking up. I ftp the uudecode.Z program from asc.purdue.edu. > I set binary mode to do this. It looks like: > -rw-r--r-- 1 rminnich 8109 uudecode > -rw-r--r-- 1 rminnich 5709 uudecode.Z > The uncompressed one was created from the 'shar' file in ~ftp/pub > at purdue. Now i load uudecode down over kermit, after > set file type binary > and on the amiga it is still 8109 bytes. ADos (v1.2) starts to read > it and crunches it for a few seconds, then > cant load uudecode: not an object file > I am going slowly nuts. Has anyone else had this problem? > When i dump the file on the amiga it looks just fine. > When i load C source down it gets there with no errors at all. > HEEEEEEELLLLLLLP! [ I apologize for replying via comp.sys.amiga, but when I ask "pathto" how to get to "udel.EDU", I get an extremely non-committal reply. . . ] The first step is to try again. In addition to "set file type binary", also enter "set block-check 3", which causes Kermit to use a CRC on the transmission (if you're not doing this already). Upload the file to your Amiga just as you have before. Then try to run the file (just for information. . .). The second step is to reverse the process -- download the object file to the VAX (or whatever), using the same procedure that you used to upload it to your Amiga. Then use diff (or another file comparison program) to compare the two files. If they are not equal, you have a suspect in your sights. If the file from the Amiga is identical with the original, then check to see that what you are downloading is really a binary for the Amiga! Finally, you should be able to end-run the problem by getting a copy of uudecode on an Amiga floppy. Uudecode appears several times on the Fish Disks (#53 is one place, I believe). Certainly someone in Delaware (udel is in Delaware, right?) should have a copy of uudecode. If you can't find a copy of uudecode anywhere, send me email, I'll send you my snail mail address, you can send me a disk and a SASM, and I'll make a copy of uudecode for you. (There's gotta be a better way, right?) Steve Rice ----------------------------------------------------------------------------- new: stever@videovax.tv.Tek.com old: {decvax | hplabs | ihnp4 | uw-beaver | cae780}!tektronix!videovax!stever
billd@crash.CTS.COM (Bill D'Camp) (07/23/87)
[]
Hmmm, I've been using kermit for a long time and have NEVER had it
add garbage to the end of a file which is why I prefer it to Xmodem.
I have never had a problem with any file downloaded with Kermit, I wish
I could say the same for Xmodem. In downloading (FTP I presume) the file
from Purdue, you said you specified "binary" mode, are you downloading
to a system with the same word size? As in Vax to Vax? If not that
could be a problem, I have had problems getting files down from a TOPS20
machine, and have had to do an intermediate transfer to a Vax. Various
implementations of FTP call it different things, but you should be transferring
in "IMAGE" mode, this insures that you get exactly what was on the other
machine, may be the same as binary but I'm not sure.
--
_ /|
\`o_O'
( ) Aachk! Phft!
U
BOINGERS WORLD TOUR 87!!!! COMING SOON TO A MOOSE LODGE NEAR YOU!!
Opinion? I thought you said onions.
UUCP: {akqua,hplabs!hp-sdd,sdcsvax,nosc}crash!billd
ARPA: crash!billd@nosc
INET: billd@crash.CTS.COM