blewis@cup.portal.com (03/24/88)
Has anyone been able to get "handshake" working as posted in comp.binaries.amiga? I managed to download, unshar, and uudecode it ok, but the result was an error code 121. I even tried hunkpad, which replied: 13 HUNK_ENDS added but to no avail. I assume that the program works, because the posting indicated that it had been tested. Therefore it is probably a problem with the uuencoding or something. Thank You, Benjamin Lewis blewis@cup.portal.coma sun!cup.portal.com!blewis
avery@puff.cs.wisc.edu (Aaron Avery) (03/25/88)
In article <4096@cup.portal.com>, blewis@cup.portal.com writes: > Has anyone been able to get "handshake" working as posted in > comp.binaries.amiga? Yes. > the result was an error code 121. I even tried hunkpad, which replied: I also had this problem, temporarily. You need to be very careful. At the end of the uuencode part 1, there's a line you need to delete. At both the beginning and end of part 2, and at the beginning of part 3, too. At the end of part 3, there's a 'size xxxxxx' line. Compare the final file size with this to see if it's right. Good luck. Aaron Avery (avery@puff.cs.wisc.edu) ({seismo,caip,allegra,harvard,ihnp4}!uwvax!puff!avery)
rayz@koko.UUCP (Ray Zarling) (03/26/88)
In article <4096@cup.portal.com> blewis@cup.portal.com writes: >Has anyone been able to get "handshake" working as posted in >comp.binaries.amiga? I managed to download, unshar, and uudecode it ok, but >the result was an error code 121. Part 2 of the posting arrived at our site damaged; sh complains about the length being wrong, and uudecode finds a checksum problem. I think at least part 2 may need to be re-posted. --ray zarling ...ihnp4!lll-crg!csustan!rayz
rmariani@watmum.waterloo.edu (Rico Mariani) (03/26/88)
In article <4096@cup.portal.com> blewis@cup.portal.com writes: > >Has anyone been able to get "handshake" working as posted in >comp.binaries.amiga? I managed to download, unshar, and uudecode it ok, but >the result was an error code 121. I even tried hunkpad, which replied: >13 HUNK_ENDS added >but to no avail. >I assume that the program works, because the posting indicated that it had been >tested. Therefore it is probably a problem with the uuencoding or something. > >Thank You, >Benjamin Lewis You seem to have the same problem that I had, there's nothing wrong with the posting really. The only problem is that the .uu.1, .uu.2, and .uu.3 files had this nice message at the top of the file telling you to delete this line and then join it with whatever. The problem is that they also had a similar line at the bottom of the file which I failed to noticed (and I bet you did too). To the moderatores. Don't do me any favours with handy dandy messages that are a pain in the *@#$@# and just tell me something obvious. If you want to do me a favour then make a little shell script that joins the three and uudecodes them. If you don't put junk and/or extra newlines at the beginning and end it's much less painful for us to unpack them. -Rico
mccarrol@topaz.rutgers.edu (Mark C. Carroll <MC>) (03/26/88)
Handshake, as distributed, was damaged by the time it got to Rutgers, at least. After several attempts at playing with it, I found the problem is in the second section of the uuencode. It's too short. Sorry, I don't have diffs on what the problem is, but the copy in the archives seems fine.. I FTPed it, and right now, I'm using the program. Perhaps the moderators could repost the second piece of handshake.uu? <MC> -- <MC>=Mark C. Carroll,Rutgers CS Student| We try to keep ourselves detatched mail to: ARPA: CARROLL@AIM.RUTGERS.EDU | It's clear who holds the key UUCP: mccarrol@topaz.rutgers.edu | Drifting though the age of reason (backbone)!rutgers!topaz!mccarrol | Now your washed up on the shore -GTR
thad@cup.portal.com (03/26/88)
Since you're using PORTAL, you may be "local" to one of my BBS systems (e.g. BBS-HT, BBS-JC, FAUG-BBS, etc.). Get HANDSHAKE from one of those BBS systems; we have both version 1.50 and 1.60b available. Caution using 1.60b though: it is extrememly susceptible to ANY garbage on the line and is extremely prone to guru or totally hang your Amiga; for that reason MOST users of Handshake have reverted to version 1.50. Also, there are several SERIOUS bugs in the VT100 emulation. I called Eric Haberfellner once, discussed this with him, offered to fix the bugs, he said "fine", I sent him a blank disk and a signed non-disclosure agreement, and he never responded since. I'm "out" one (expensive) SONY DS/DD 3.5" disk. :-(
drs-ano@duvan.nada.kth.se (Gunnar Nordmark) (03/26/88)
In article <4096@cup.portal.com> blewis@cup.portal.com writes: >Has anyone been able to get "handshake" working as posted in >comp.binaries.amiga? I managed to download, unshar, and uudecode it ok, but >the result was an error code 121. I got it working, after deleting some @#$& lines saying * end of part 1 * etc It's the BEST emulation of VT100 (VT102/VT52) I've ever seen! It passes all the tests and demos of VT100 that I found on our VAX with no problems. Unfortunately it's *useless* to me since it doesn't support foreign keymaps. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ VT100R2.8 does that, AND I LOVE IT! SNAIL: Gunnar Nordmark VOICE: +46 8 755 42 52 (Abroad) Nora strand 5 08 - 755 42 52 (Sweden) S-182 34 DANDERYD SWEDEN EMAIL: nordmark@epsilon.stacken.kth.se
840493n@aucs.UUCP (Bill Nickerson) (03/27/88)
Can someone please re-post part 3 of HandShake 1.60b? I received pts 1 and 2
but no part 3. Pleeeeeeeeze, if someone has it either post it or email it to
me at the address in my signature. I would be VERY much obliged. I am
currently using the first version of HS and have fallen in love with it.
Thanx in advance.
...Bill
--
Bill Nickerson Tel: (902)542-7925 |
Acadia University +------------------------+
Wolfville, NS | BitNet - 840493n@Acadia
Canada, B0P 1X0 | UUCP - {uunet|watmath|utai|garfield}dalcs!aucs!840493nncreed@ndsuvax.UUCP (Walter Reed) (03/28/88)
In article <3730@watcgl.waterloo.edu> rmariani@watmum.waterloo.edu (Rico Mariani) writes: }You seem to have the same problem that I had, there's nothing wrong with }the posting really. The only problem is that the .uu.1, .uu.2, and }.uu.3 files had this nice message at the top of the file telling you to }delete this line and then join it with whatever. The problem is that }they also had a similar line at the bottom of the file which I failed to }noticed (and I bet you did too). To the moderatores. Don't do me any }favours with handy dandy messages that are a pain in the *@#$@# and just }tell me something obvious. If you want to do me a favour then make a No, please keep adding these lines at the bottom... Us unfortunate people on BITNET have this (&*^^*& bug that TRUNCATES FILES!!! We lose the last line or two in files OFTEN!!! BITNET FLAME ON *** Alright guys, I've let my sysadmin know about this but so far, nothing has been done about it yet. BITNET also wraps lines or just plain truncates them. Our site has no choice but to use bitnet due to the fact that it is an underfunded state university in nowheres ville. We don't have the money to call uunet for much (we do mail through it though.) Maybe files should be encoded so that they come through un-damaged (I'm talking BITNET to BITNET and not the whole net.) Why is BITNET so set on PUNCH CARD technology???? Tabs expanded to spaces, trailing spaces chopped, files strangely truncated, lines wrapped or cut at 80 columns, this has GOT to be FIXED. We also lose files! It is REALLY irritating to have only 2 parts of a 3 part posting make it through this MESS OF A NETWORK. *** flame off (I've calmed down somewhat.) Moderators: I wouldn't mind if you posted everything in uuencoded zoo! It would allow me to get files accurately. There would probably be too much opposition to this however. How about a vote? }little shell script that joins the three and uudecodes them. If you }don't put junk and/or extra newlines at the beginning and end it's much }less painful for us to unpack them. } } -Rico I always check the top and bottom of EVERY file that comes over the net (OK, only sources and binaries...) I think it should be standard procedure... When you buy a house, you always look at the basement and the attic... (so what if that doesn't make sense? :-)) -- /* Walter Reed UUCP : uunet!ndsuvax!ncreed Internet : ncreed%NDSUVAX.BITNET@CUNYVM.CUNY.EDU Ph 701-235-0774 Bitnet : ncreed@ndsuvax OR NU105451@NDSUVM1 ------------------- */
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (03/30/88)
Wow, this is the last place I expected to find a flame at BITNET and how to send news across BITNET, but here it is so here it where I'll answer it. I'm answering in public for everyone's (especially the moderators) benefit and because I have 2+ years experience with doing news across BITNET. Also, I'm cross-posting to news.misc with followups directed there. news.misc readers -- the posting that Walter is responding to is one complaining about either a lost source posting, or a mangled one. I forget which. In article <747@ndsuvax.UUCP> ncreed@ndsuvax.UUCP (Walter Reed) writes: >BITNET FLAME ON *** >Alright guys, I've let my sysadmin know about this but so far, nothing has >been done about it yet. Calm down. There's not much he can do about it. >BITNET also wraps lines or just plain truncates >them. Yes. That's because IBM machines see *everything* as a stream of cards. Sometimes the cards are rather wide -- I understand that there's a file format which has cards up to 65k characters wide -- but it's cards (er.. records, sometimes varying length) all the same. >Our site has no choice but to use bitnet due to the fact that it >is an underfunded state university in nowheres ville. >We don't have the >money to call uunet for much (we do mail through it though.) I know. I've been there. I feel for you, *really*! >Maybe files >should be encoded so that they come through un-damaged (I'm talking BITNET >to BITNET and not the whole net.) Now you're talking. As I recall the setup at North Dakota the news arrives at NDSUVM1 before it goes to NDSUVAX. If so there's nothing you can do -- at least not that I know of. Between vaxes you have compatible file semantics and encoding/decoding programs. One of my two BITNET feeds is to a VMS vax cluster at the U of Louisville and I use the following scheme (The other is an IBM): Sending: compress file | btoa | netcopy netnews@ulkyvx03 Receive: atob file | uncompress | rnews The same scheme also worked well going to/from a 3b20 at GaTech. (btoa/atob are part of the v4 compress distribution -- the newest versions of uuencode should also work as well, that is the versions which add the crc to the end of the line which (as a side effect) gaurantees that lines with trailing blanks aren't truncated). This exact scheme won't work if one of the sites is an IBM machine. The IBM machines don't have compress, for instance. Now possibly you could convince something like atob/btoa to run on the IBM machine, but even if you did that the news get's filtered through the file system of the IBM machine and who knows what transformations will be done in the bowels of those high speed card punches? >Why is BITNET so set on PUNCH CARD >technology???? Tabs expanded to spaces, trailing spaces chopped, files >strangely truncated, lines wrapped or cut at 80 columns, this has >GOT to be FIXED. You want a historical lesson too? I think the short answer is that IBM standardized their stuff "too early". They standardized when punched cards were the norm. Sigh, youngsters! :-) >We also lose files! It is REALLY irritating to have >only 2 parts of a 3 part posting make it through this MESS OF A NETWORK. >*** flame off (I've calmed down somewhat.) I have news for you ... Even backbone sites on the internet who use NNTP for the bulk of their news traffic lose things. (i.e. us, hopefully I have that problem fixed :-) ) >Moderators: I wouldn't mind if you posted everything in uuencoded zoo! >It would allow me to get files accurately. There would probably be too much >opposition to this however. How about a vote? This sort of thing has been suggested many many many many many times, the objections include: 1. Compression -- It's a fact that when you compress a file then compress the compressed file that the file gets bigger. One of the Lempel-Ziv gang believes that if it *doesn't* get bigger then there's something wrong with your compression algorithm, that you're not getting as much compression as you could. Anyway, my memory of zoo (I've never used zoo) is that it uses compress in the middle of it. It would not be a good idea to have something compressed going through news because many of the feeds where it matters (i.e. long distance uucp) already compress their news batches. 2. Unreadability -- Somebody sitting in rn seeing this posting of source for something or other can, right now anyway, read down into the posting a ways and find the README and decide then if s/he wants to save this source away. With a uuencoded zoo (or any other archived format) you have to save the posting, hassle with it a few minutes to get it unarchived, THEN you get to read the README or whatever. It's not as convenient. 3. Not everybody has the same archivers -- I don't have a copy of zoo around. I know, look in sources.amiga because the new version is right there (I think). I also don't have it on my Unix machines because I have never had the time to look at it. We also don't have arc on our Unix machines because I've never had the time to track down a working version... We do have tar and cpio :-). -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- I don't have a Blue bone in my body!