|
There are several communications and networking tools that are available
on nearly every UNIX system. This document will go over a handful of the
more standard ones, including clients that allow you to login
remotely, transfer files, send e-mail,
and talk (or refuse to talk) in
real-time.
Logging in Remotely
The ones that are used most often are telnet and rlogin, which let you
login to the system remotely. Telnet is used most often. There are telnet
clients available for nearly any platform, though usually UNIX systems
are the only ones running a telnet server. Telneting into a UNIX machine
will allow you to use a command line shell, including full screen display
programs if your terminal is set up properly. Rlogin (short for Remote-LOGIN)
looks similar to telnet on the surface, but uses a different set of protocols.
More information is exchanged between the client and server during an rlogin
session than during a telnet session. This gives it more functionality,
but also creates some security risks if not used carefully. One of the
main features of rlogin is the .rhosts file. This is a file that a user
can have in his or her home directory that lists a set of machines and
usernames that are to be considered "trusted". This allows the user to
login to one of the trusted machines, and then rlogin into the main machine
without supplying a password. I'm sure it's obvious at this point
why .rhosts files should be used with care. Besides rlogin, there is a
whole suite of remote applications including rcp (remote copy), rsh (remote
shell) and rexec (remote execute) that rely on the .rhosts file to determine
trusted users and machines. Telnet and rlogin are both executed from the
command line, with the remote host address as an argument.
File Transfer
Another useful tool is sftp, or Secure File Transfer Protocol. With an sftp client,
you can log into any machine that is running an sftp server (no matter what
platform) and transfer files back and forth. When you login using sftp,
you do not get a shell command line, you stay within the sftp client, but
you navigate the directories as if you were in a shell. Using the commands
put and get you can transfer files to and from the remote host. One important
thing to keep in mind is that executable programs, compressed files, and
any other binary files must be transferred in binary mode. Most
sftp
clients default to ascii (text) mode, so to be safe type binary at the
sftp> prompt. Some sftp clients will determine the mode automatically. SFTP
sessions can also be automated from a UNIX machine by using macros in your
.netrc
file.
Electronic Mail
There are several mailers available for UNIX systems. The standard mailer
we use is Mail (invoked by mail --note the case; you see, our systems have
'mail' aliased to /usr/ucb/Mail in the default login files). Mail is very
simple to use; essentially, you type 'mail' and you read any mail messages
waiting for you. Sending mail is like- mail userid1 userid2...useridn.
Note: do NOT put the carbon copies
here; you put them at the end of the mail session, or inside the mail item
(see below). If you put it on the command line, you try to send mail to
user "cc:" which usually does not exist.
An alternative to the standard mailer is pine. Pine uses a full screen
display, which most users find a lot easier to use than mail. It saves
mail in "folders", giving you an inbox, saved-mail, and sent-mail folder
by default, and allowing you to define other folders to categorize your
mail with.
Another popular mail system available on our UNIX systems is MH. MH
differs from Mail in that MH is a collection of small programs that you
execute from the shell. MH is more powerful and customizable than Mail,
and is on all of the CSC UNIX systems.
Real-Time Communication
On UNIX machines, you have two ways of communicating in real-time. The
most preferred way is 'talk.' Talk is a two-way real-time communications
program, letting you see what the other person types character-by-character
(as opposed to the IBM mainframe, which is line by line). To initiate a
talk, type talk userid@address [tty] (the @address part is not
needed if you are talking to someone on the same machine as yourself, and the
tty part is only necessary if you wish the message to go to a specific
tty and not the first one the system finds). The other party will get a
talk daemon message:
Message from Talk_Daemon@lewhoosh.umd.edu at 17:46 ...
talk: connection requested by matthews@lewhoosh.umd.edu.
talk: respond with: talk matthews@lewhoosh.umd.edu
...and he/she can either ignore the message and be bothered for a while,
or respond with a talk command (the system will tell you what to type to
answer the request -- "respond with:..."). We will ignore the fact that
talking to oneself is a sign of impending doom. To end the talk session,
just hit ^C (if nobody answers for a few 'rings,' then it's safe to assume
they aren't going to). Note that your terminal must be set correctly (including
type, number of rows, and number of columns) for a full- screen environment,
else ... well, let's just say you won't like the results otherwise and
leave it at that. If you get a message:
[Checking for invitation on caller's machine]
that could mean one of two things. One: The other machine is a Sun workstation
running BSD 4.2 talk (while the rest of the world is running BSD 4.3 talk)
and the protocol is not compatible. You can try to use the command "otalk"
instead, for Old talk. If that doesn't work, then Two applies. And Two
is: something is muffed up. It could be the network is down, or it could
be the other system is having problems firing up the talk daemon. Either
way it's related to the protocol not being met and there's nothing you
can do about this situation except wait. If you get the message:
Target machine is too confused to talk to us
then you've discovered a funny error message most likely written by someone
strung out on caffeine at 3 in the morning.
The other method of real-time communications on UNIX is the 'write'
command. This will send a one-way message. The format is pretty much the
same as the IBM mainframe's TELL command: write <userid >[tty],
where <userid >is
the user you want to communicate with and the optional tty specifies which
tty to send the message to if/when the user is logged in more than once
(otherwise, write will send it to the first one it finds). Note that write
will not work across systems, so you have to be logged in to the same machine
your recipient is on. When you first issue the command, the recipient will
get a message telling him/her you are sending him/her a message. Then you
type in your message and end it with a ^d (UNIX EOF), and the recipient
will see it (they will get it line by line as well). You can also use i/o
redirection (write <userid >< message.file or
echo <message>|
write <userid>).
How Not to Receive
Messages
The commands for enabling/disabling messages to your tty, and thus your
screen, are mesg y/n. Some people like to put mesg nin their
~/.login
file just to make sure that people won't interrupt them. This is the default
setting for the WAM machines, so in order to receive real-time messages
on WAM you need to give a "mesg y" command.
The command who will tell you who is on the machine that you
are on, or you could use
finger @[machine-name]
to see who is on a remote machine. In order to make sure you are not
interrupting someone who is busy, the "w" command will tell you what people
on your machine are doing.
One little bit of netiquette: try not to send writes or talk requests
to people who do not want to be disturbed! This includes sending random
messages to people you don't know just because you're bored, and also sending
them to anybody who is using a full screen program, such as a text
editor or maybe another talk session.
|
