User Communication
If you are running a multiuser system like Linux, you
should expect to find other users on your system. (I guess that's why it is a
multi-user system.) Although there are many built-in mechanisms to keep users
separated,
sometimes you will want to communicate with other users.
Linux provides
several tools to do this, depending on exactly what you want to accomplish. If
you simply want to send a quick message to someone, for example, to remind him
or her of a meeting, you might use the write program, which sends (writes) a
message to his or her terminal.
In contrast to some other systems (say,
the winpop mechanism under Windows), each line is sent when you press Enter. If
you are on the receiving end of the message, the system lets you know who sent
you the message.
If the person you are trying to contact is logged in
more than once, you need to specify the terminal
to which you want to send the
message. So, if I wanted to talk to the user jimmo on
terminal
tty6, the command
would look like this:
If you omit the terminal,
write is kind enough to let you select which terminal
to which you want to send
the message.
It might happen that someone tries the above command and
receives the following message:
write: jimmo has messages disabled.
This message means that jimmo has used the mesg command to turn
off such messages. The syntax for this command is
to turn it off and
to turn it on. Unless the system
administrator
has
decided otherwise, the command is on by default. I have worked on some systems
in which the administrator
changed the default to off.
An extension of write is the wall command. Instead of simply writing the
message
to a single user, wall writes as if it were writing on a (where else) wall. That
is,
everyone can see the message when it is written on a wall, and so can every
user. The wall
command is often used by root to send messages about system status (e.g. when
the system is
about to be shutdown. Even if a user has disabled messages, the root user can
still send them
messages using wall.
If you want to
have an interactive session, you could send write messages back and forth. On
the other hand, you could use the talk program that was designed to do just
that. When talk first connects to the other user, that other user sees on his or
her screen
Message from TalkDaemon@source_machine...
talk: connection requested by callers_name@his_machine
talk: respond with: talk callers_name@his_machine
As the message indicates, to respond, you would enter
talk callers_name@his_machine
You might have noticed that you
can use talk to communicate with users on other machines. If you omitted the
machine name, talk would try to contact the user on the local machine
(localhost). The preceding message would simply say
talk: connection requested by callers_name@localhost
You can also disable talk by using the mesg command.
It is common practice to use a couple of terms
from radio communication when using talk. Because you cannot always tell when
someone is finished writing, it is common to end the line with -o (or use a
separate line) to indicate that your turn is "over." When you are
finished with the conversation and wish to end it, use oo (over and
out).
Both of these mechanisms have some major problems if the user is not
logged in: they don't work! Instead, there's mail or, more accurately,
electronic
mail (or e-mail).
On most UNIX
systems (including Linux), e-mail is
accessed through the mail command. Depending on your system, the mail program
may be linked to something else. On my system, the default was to link to
/usr/bin/mail.
There are several different programs for sending and
viewing mail. You could use one mail program (or mailer) to send the message and
another to read it. Often the program that you use to read your mail is called a
mail reader or, simply, reader. Before we go on to the more advanced mail
programs, I want to talk about the most common mail program and the one that is
most likely to be on your system. (From here on, I will be referring to e-mail
simply as mail.)
Mail comes in units called messages. Whether you
use UUCP
or the Internet, mail is sent back and forth in messages. However, once
the message has reached its destination, it is usually tacked onto the end of an
existing mail file. There is usually one mail file per user, but that single
file contains all of a user's messages (that is, all those that haven't yet been
deleted).
To read your mail, you can use three primary character-based
programs: elm, pine, and the default
reader, mail. Actually, you can use all
three programs to send mail as well as read it. Each program has its own
advantages and disadvantages. Although the mail
interface looks menu-driven, it simply scrolls the information across
the screen. Both elm and
pine have much more complex menuing systems. Because
of this, mail is easier to learn, but
you can do much more with the other two programs.
All three programs
understand the concept of a "folder" in which you can store messages.
This allows you to develop a hierarchy of files that is no different from the
normal file system. How the folders are created and managed depends on the
program you are using. Therefore, I would suggest that once you decide to use a
specific program, stick with it because the files may not be
compatible.
In keeping with the basic premise of this book, I must treat
these programs as applications. Therefore, I won't go into any more detail about
them. Instead, I suggest that you install all three and see which one suits your
needs best. If you have the space, you may consider providing all three for your
users. The man-pages provide a great deal of information and each program has
its own on-line help.
If you are using
the X-Windowing System and a desktop
environment
such as the KDE, you have
a much larger and varied choice, such as my favorite
Kmail. Prior to using kmail, I was using
Netscape Communicator. Although the Netscape Communicator has many useful
features, Kmail had the features I really need. Plus, I use the KDE as my
desktop environment and Kmail fits into the KDE architecture. (I will talk more
about the KDE and many of the programs when I get the time.)
|