Thread View: comp.bugs.misc
5 messages
5 total messages
Started by Dana Uehara c/o Andrew Nash
Sun, 06 Sep 1992 09:44
"talk" bugs on the "uhunix" system
Author: Dana Uehara c/o Andrew Nash
Date: Sun, 06 Sep 1992 09:44
Date: Sun, 06 Sep 1992 09:44
18 lines
1165 bytes
1165 bytes
Help!! I've had some problems with using the "talk" command on this computer system (uhunix.uhcc.hawaii.edu) and would appreciate any advice. The "talk" command worked okay at one time. Now, however, I've run into problems with using "talk." An attempt to "talk" to a user on a different system gave me the message "Trying to connect to your party's talk daemon," while an attempt at using talk with this signon (i.e. "talk anash") resulted in the message "Checking for invitation on caller's machine." Can anyone offer any advice? Thanks!! -- ======== Dana Uehara [c/o <anash@uhunix.uhcc.hawaii.edu> (Andrew Nash)] ======= "Leave this to my personal self... Brilliant, yes-no?" -- Don Karnage
Re: "talk" bugs on the "uhunix" system
Author: Jay Vassos-Libove
Date: Sun, 06 Sep 1992 14:19
Date: Sun, 06 Sep 1992 14:19
21 lines
1690 bytes
1690 bytes
This is not a bug, but instead a version incompatibility. When UNIX (the operating system itself, not any particular machine) moved from Berkeley version 4.2 and version 4.3, the talk protocol changed, in order to accomodate a newer protocol that could handle talking between machines with different architectural byte-orderings. What this comes down to is that machines running a BSD 4.2 version of "talk" can not talk to machines running the BSD 4.3 version of "talk". Some newer systems provide "otalk" to talk to older machines, or "ntalk" to talk to newer ones. Try those, and also try reading the manuals and asking locally for assistance, as some sites also provide their own changed talk programs to meet this need. Posting to the net before checking locally is not as effective. Best wishes... -- Jay Vassos-Libove libove@alf.dec.com Digital Equipment Corporation decwrl!alf.dec.com!libove Atlanta Customer Support Center Opinions? They're mine, mine, all mine! Alpharetta, Georgia and D.E.C. Can't have 'em!
Re: "talk" bugs on the "uhunix" system
Author: Craig Richmond - division
Date: Mon, 07 Sep 1992 09:15
Date: Mon, 07 Sep 1992 09:15
31 lines
2008 bytes
2008 bytes
libove@libove.alf.dec.com (Jay Vassos-Libove) writes:
>This is not a bug, but instead a version incompatibility. When UNIX
>(the operating system itself, not any particular machine) moved from
>Berkeley version 4.2 and version 4.3, the talk protocol changed, in
>order to accomodate a newer protocol that could handle talking between
>machines with different architectural byte-orderings. What this comes
>down to is that machines running a BSD 4.2 version of "talk" can not
>talk to machines running the BSD 4.3 version of "talk". Some newer
>systems provide "otalk" to talk to older machines, or "ntalk" to talk
>to newer ones. Try those, and also try reading the manuals and asking
>locally for assistance, as some sites also provide their own changed
>talk programs to meet this need.
If anyone is interested, talk for the Macintosh by Peter N Lewis will talk
to any machine under (and including) the sun. The only rumoured failure
was talking to a mac running aux. Sad hey.
I am sure he would be willing to mail anyone a copy of the source code or
you can ftp it from an info-mac archive
/info-mac/source/pascal/talk-106.hqx
Do the world a favour and port the internal bit that connects to any
machine.
Craig
--
Craig Richmond. Computer Officer - Dept of Economics (morning) 380 3860
University of Western Australia Dept of Education (afternoon)
craig@ecel.uwa.edu.au Dvorak Keyboards RULE!
"Only users are allowed to make messes on their computers" I.M.VI
Re: "talk" bugs on the "uhunix" system
Author: Jay Vassos-Libove
Date: Mon, 07 Sep 1992 14:57
Date: Mon, 07 Sep 1992 14:57
26 lines
1964 bytes
1964 bytes
It isn't a matter of porting the bit of code - there are two different talk protocols out there. It would be possible to modify the talk code to try its default protocol and, failing that, try the other, but it would be heuristic, and not 100% reliable. It would also lead to rather long delays in getting connected, sometimes, plus would fail badly if the network connection was down at the time. It makes more sense, for now, to have the two versions of talk available. The symptom of reaching a talk daemon of the other protocol version is easily recognizable (as posted by the first person to ask here) and running a different program isn't so bad. The real problem is that talk runs as root, and you can't just port the code and install it - the system administrators at every site would have to evaluate its safety and then choose to install it, and then maintain through operating system upgrades. The best possible solution is to get the people at the remote sites running the older version to UPGRADE. -- Jay Vassos-Libove libove@alf.dec.com Digital Equipment Corporation decwrl!alf.dec.com!libove Atlanta Customer Support Center Opinions? They're mine, mine, all mine! Alpharetta, Georgia and D.E.C. Can't have 'em!
Re: "talk" bugs on the "uhunix" system
Author: Dana Uehara c/o Andrew Nash
Date: Wed, 09 Sep 1992 03:55
Date: Wed, 09 Sep 1992 03:55
14 lines
989 bytes
989 bytes
Yours truly writes: > >The "talk" command worked okay at one time. Well, apparently the problem has fixed itself... I just used the "talk" command earlier today and discovered that it worked fine. I think I just needed to give the system time to connect properly. Thanks for all the advice! -- =================== Dana Uehara <anash@uhunix.uhcc.hawaii.edu> ================ "How many times do I gotta tell you -- do what I think, not mean what I say?!" -- Pete
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads