bleke@ritcsh.UUCP (Blake Ramsdell) (10/24/87)
Dick and netland: I have had the *HARDEST* time getting the lims out of uuencoded format. Let me explain my problem: In article <814@plx.UUCP> dick@plx.UUCP (Dick Flanagan) writes: > >The document was created, ARC'ed, and UUENCODE'ed on a PC, Does this mean that I have to run UUDECODE on a PC, or will the version on our PDP 11/70 running UN*X 2.9 work? If not, where can I get a copy of UUDECODE (not in UUENCODED format =-)) for my PC? >Finally, any reasonable version of ARC (ARC, ARCE, >PKXARC, etc) can be used to extract the two files contained >therein (READ.ME and LIMEMS40.DOC). Now, is ARC 5.12 a reasonable version? What is the minimum version of PKXARC needed? Here's what I did: 1) saved all files from net onto account 2) deleted header and footer from each file in VI (file 1, 2, and 3 were exactly 700 lines long after deletion. File 4 had an 'end' as the last line. 3) did a 'cat file1 file2 file3 file4 > outfile' 4) did a 'uudecode outfile' 5) got the highly sophisticated and descriptive message "Short file" for my troubles. 6) took resulting .arc file and downloaded it to my PC's Limited AT using the KERMIT file transfer protocol (file was about 80,000 bytes) 7) did an 'arc x filename (can't remember the name of the file)' on my PC 8) got 'Extracting LIMEMS40.DOC' 9) system locked up I also tried variations on steps 3 and 4 (i.e. 'uudecode < `cat file1 file2 file3 file4`' etc.) with the same results. I also tried pkxarc in step 7, with the same results. HELP! Any comments or hints would be GREATLY appreciated! Thanks in advance... =-) bleke -- __ Blake C. Ramsdell / ' | Computer Science House "We have a quality | S|-| Rochester Institute of Technology control that is \__, | Rochester, NY 14623 equalled only by NASA" UUCP :...rochester!ritcv!ritcsh!bleke -- Jack Lemmon: "The BITNET: BCR3458@RITVAX China Syndrome"
ewong@utgpu.UUCP (10/26/87)
In article <8066@ritcsh.UUCP> bleke@ritcsh.UUCP (Blake Ramsdell) writes: > 6) took resulting .arc file and downloaded it to my PC's Limited AT > using the KERMIT file transfer protocol (file was about 80,000 bytes) Please remember to set KERMIT to binary mode before downloading any .arc file. Eddy Wong Bitnet: EWONG at UTORONTO
dick@plx.UUCP (Dick Flanagan) (10/27/87)
Summary: Expires: Sender: Followup-To: In article <8066@ritcsh.UUCP> bleke@ritcsh.UUCP (Blake Ramsdell) writes: >Dick and netland: > I have had the *HARDEST* time getting the lims out of uuencoded format. [...] > 5) got the highly sophisticated and descriptive message "Short file" > for my troubles. I have seen the "Short file" message before in cases where part of the mail system has stripped off trailing blanks from the uuencoded files. Blanks are, of course, significant to UUDECODE. Blake, the only line which should be short is the very last one before the "end" statement. If you see some of the encoded lines that look like they have one or more spaces at their end, make sure that there REALLY are spaces there and not just a <CR>--those lines should never be "short." -- Dick Flanagan, W6OLD I'll take a drug test when UUCP: ...!ucbvax!sun!plx!dick Reagan takes an IQ test. GEnie: FLANAGAN
heiby@mcdchg.UUCP (Ron Heiby) (10/31/87)
This has happened before, and I'm sure that it will happen again. We have just seen a well-intentioned person devote a great deal of personal time to sharing some important information with the net. That person has attempted to reduce the volume of information passed between sites and has, in the process, actually increased it. I am not commenting on the wisdom of posting such a long document that can be had free with just a phone call. There may very well be people out there that couldn't wait for it to be mailed to them. I really want to talk about "saving net bandwidth". The LIM EMS document was typed in (I respect anybody who can type that much at a time.). Then, since it was so big, the poster used ARC to squeeze some size out of the file. Naturally, the .ARC file was considerably smaller than the original text. There's a problem now, though. We can't send binary data in news articles. So, the obvious solution is to run the .ARC through uuencode to produce a printable-ascii-ized version. The resultant file is bigger than the .ARC, but still a fair amount smaller than the original. Since it's so big, the poster splits the .ARC into four chunks that can be sent in seperate messages, which he does. Now, it's zapping around the globe to all the sites on Usenet, where it eventually reaches my site. I think to myself, "Neat! I'd like to read that." So, I must edit the four messages and concatenate them together without the header and signature information (no big deal). Ok, now what? Well, if I'm lucky, I happen to have a copy of uudecode around to turn the file back into a .ARC. uuencode and uudecode have been posted to numerous newsgroups on numerous occasions, so there's a good chance that I either have it or could have had it if I had had the good fortune to realize that I would need it some day. Now, I have a .ARC file on my UNIX system. Wonderful. At this point, I must either have a *working* version of ARC running under UNIX (not nearly so certain as with uudecode) or I must have it on my PC at home (much more likely, but still not a certainty) as well as a method of file transfer that is 8-bit transparent, like kermit running on *both* my UNIX box and my pc, as well as being willing to foot the bill for a large number of "message units" to the Local Operating Company (Ma Bell). So, I ship it down to my pc, extract the spec from the .ARC, and now I have the information I desired. Unfortunately, the printer I have at home is a 7 year old Epson, which is quite serviceable, but I really don't want to print a couple of hundred pages on it over the next 48 hours, so I plan to send it *back up* to my UNIX box, where I can zap it out on my laser printer. Oops! The document is not formatted with formfeeds. It has ugly blank lines in it with the implicit assumption that my laser printer happens to have 66 lines per page. Arggh! Oh, what's this? Another file was in the .ARC. What's it say? Oh, I can get a copy of this for free? I don't have to use $10 worth of toner in my laser printer? Great!! Again, I'm really not talking about the wisdom of posting what can be had for a phone call. Nor am I really talking about the amount of effort that it would take someone to get any benefit out of the posting at all, plus the number of programs required for the task (uudecode and ARC, at least). Here's what this message is really about: Net Bandwidth. The whole point of making people go to all the work of using uudecode, ARC, etc was to save net bandwidth, right? Well, on those links where the administrators care about how much things cost, they are running "compress" on the news articles that pass between their sites. Let's look at how much savings we really had by working as hard as we did. I took the uuencoded .ARC file and ran it through "compress" on my UNIX system. The resulting file was 153,259 bytes long. Then, I took the originally typed in document (the product of running the file through uudecode and ARC) and ran *it* through "compress". The resulting file was 96,373 bytes long. So, for those news links where the administrators care about costs, we went through all kinds of extra work to COST THEM AN EXTRA 55K BYTES! Come on, people. If it's ASCII text, like a document or source code, POST IT IN CLEAR TEXT! Thank you very much. -- Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix "I know engineers. They love to change things." McCoy
w8sdz@brl-smoke.UUCP (11/01/87)
I appreciated the fact that the LIM EMS 4.0 spec was posted in ARC
form. When I extracted the document and got no error messages from ARC
I know I had an *exact* copy of what was posted.
When Usenet fixes whatever mungs some plain-text postings I will be
sympathetic to the argument that it took more resorces to send the
uuencoded ARC. Did you know that the "compress" program has NO error
checking? Try deliberately truncating a compressed file and then
uncompress it. There is no warning that it's munged! It is my opinion
that this is the major cause for inaccurate text transfers on Usenet.
ARC includes a CRC for each member file. The CP/M program CRUNCH, a
decendant of compress, also includes a CRC *and* the name of the
original file. The authors of crunch would do well to look at CRUNCH to
see how it should be done!
--
Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZdick@plx.UUCP (Dick Flanagan) (11/02/87)
Summary: Expires: Sender: Followup-To: In article <2218@mcdchg.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes: > [...] Oops! The document is not >formatted with formfeeds. It has ugly blank lines in it with the >implicit assumption that my laser printer happens to have 66 lines >per page. Arggh! [...] I tried to format the document into as generic a form as I could. That is why, when the document left this site, it did indeed contain formfeed characters for each page. If they are no longer there in your copy, I am at a loss to explain it. -- Dick Flanagan, W6OLD I'll take a drug test when UUCP: ...!ucbvax!sun!plx!dick Reagan takes an IQ test. GEnie: FLANAGAN