MY.GUIDE.TO.TALK ================ Peter Hinxman 12th May 1994 Version 1.1 [[ this file is found in ]] [[ /aber/mph/pub/docs/my.guide.to.talk ]] Contents: 1. Basic guide to set up yourself up to use talk. 2. Using talk on Computer Unit machines. 3. Problems in making a talk connection to another machine 4. Other points to note. Section 1. Basic guide to set up yourself up to use talk. ============================================================= First of all, to allow messages to come onto the screen telling you that another user wants to talk to you, you need to have the line mesg y in your .mshprofile file ( the default is to have it set to n, so you don't get interrupted ), or when you log on type your_unix_prompt_$ mesg y Section 2. Using talk on Computer Unit machines. ==================================================== To find out if the person you want to talk to is logged on ( if not then you'll have to email them :-), type your_unix_prompt_$ finger This produces a list of all users logged on to the SAME machine as you. eg. deca.aber.ac.uk. If the person you wish to talk to, is in there ( eg. mph ) then just type your_unix_prompt_$ talk mph If they're not on then they might by on the oracle machine or on the decb machine, so use: your_deca_unix_prompt_$ finger @decb If the other person is logged on to decb then type: your_deca_unix_prompt_$ talk mph@decb If you are on the deca, decb, or oracle machines then there are on-line manual pages for these commands. your_deca_unix_prompt_$ man talk Section 2. Problems in making a talk connection to another machine ====================================================================== example> I'm trying to contact a friend at some other site/machine example> using the TALK command. My computer gets as far as saying example> that it is waiting for a response from the caller's machine, example> which never comes. Is there a problem with my computer, I example> have mesg y in my .login file, BACKGROUND REASON: ------------------ Well, in earlier versions of BSD code there was the first `talk' protocol. This worked ok-ish, but was upgraded to use a completely different way of working. Most manufacturers updated their versions of the talk code to reflect the new approach, and everything was almost wonderful. Sun on the other hand didn't take this new approach and consequently their code doesn't interact with other peoples code and so talk sessions between Sun machines and non-Sun machines are a tad more complex. The old version of talk has become known as "otalk". Now, there is also a public domain software called `ytalk' which attempts to interface to both sets of protocols, by listening to the response it receives when it tries to set up a talk session with another computer and choosing the appropriate one to use. Unfortunately, it is not always successful in conversing with *all* forms of talk, and so you may find more success if both parties use "ytalk". This is on the DEC mainframes and but unfortunately is not on the Computer Science Suns. SOLUTION: --------- To summarise how to communicate between different machine types: machine types: SUN - SUN: try talk on both Suns ( although actually running old talk protocol ) SUN - Non-SUN try talk on Sun, otalk on non-Sun Non-SUN - SUN try otalk on non-Sun, talk on Sun Any - Any try ytalk instead of talk above, and hope for the best ! Section 3. Other points to note. ==================================== Several other points spring to mind as to why you have not been successful using talk. i. Some systems administrators at other sites do not like their users to use talk, especially to other sites ( as it can be bandwidth intensive ) and so block any talk attempts passing through their site routers/gateways. So if you are experiencing problems to one particular site but can get through to others, it may be worth your while contacting the root@other.site to ask if they allow talk sessions and which version they are running ( if they have a Sun :-). ii. example> I've got my friend's email address at Imperial College example> and trying to set up a talk session to them. When I example> try this with "talk fred@ic.ac.uk" I get the response: example> ic.ac.uk is an unknown host example> But this can't be so as email works to them ok. When you use email, you just specify the domain/establishment ( eg. aber.ac.uk ) that the recipient is in, and the system interrogates the recipient's directory of machines to discover which is the mail machine, with talk you need to know EXACTLY which machine your friend is CURRENTLY logged onto. If the user is not logged on then, then you will get an error message telling you so. In other words you may have to type talk fred@sun1.ic.ac.uk or whatever machine name your friend is on. iii. Some institutions prefer to use email aliases for all contacts, so that all email for users there is *redirected* to their mailboxes instead of going straight there. As an example, suppose Fred Bloggs has an account there. His login id may be fb123, but his email account may be f.bloggs@ic.ac.uk . Therefore as the talk command interrogates the machines at IC, it only deals with login ids, and not email aliases. This method is how email to "root@aber.ac.uk" gets redirected to go to "operator@aber.ac.uk". As you can begin to appreciate, talk is not necessarily an easy facility to use !! If you have any problems on this, please contact the advisory service.