jkp@cs.HUT.FI (Jyrki Kuoppala) (05/05/91)
In article <kre.673344580@mundamutti.cs.mu.OZ.AU>, kre@cs (Robert Elz) writes:
[ describes a zephyr-like / write-like system on which you can control
the appearance of the arriving message ]
I did something like that when getting familiar with SunRPC. It's a
bit buggy, but the idea is basically the one you're after, I think.
Also, it appears that SunRPC is not very good for this so the program
should be rewritten to work on top of a tcp protocol (funny, when it
was just an exercise in SunRPC to start with ;-).
Here's the README file; the package is in nic.funet.fi,
pub/unix/tcpip/rmsg.tar.Z. If anyone is willing to adopt it and make
it better, feel free.
This directory contains a messaging system which can be used to send
write-like messages to logged-on users. The system can cross machine
boundaries, so if another machine has the rmsgd program running, you can
send messages to users on it.
The system also allows bitnet virtual machine-like 'virtual users'
to whom any user can send messages and they can answer the messages.
The rmsgd server makes this possible by allowing a command 'exec' in a users
.msgconf file, and whenever the user receives a message this command is
executed and the message is piped to it.
It is also possible to log incoming and outgoing messages and resend previous
sent message. You can specify a file to which the last (or every) incoming
message will be stored.
Using the programs:
-------------------
Rmsgd:
Rmsgd is the server program for the system. It should be started by root,
but for now it works even if started by ordinary users, even though
some capabilities are disabled for security reasons (that is, exec and
logging of incoming messages, since that would be done by the user-id
who started rmsgd and not the receiver).
At any time, there should be only one rmsgd running. It doesn't do any harm
to have several rmsgds other than the newly-started servers unmap the
previous and thus the previous servers are unusable.
The server should be named 'rmsgd' to have it start as a daemon.
Rmsg:
Rmsg is the client end of the system. Rmsg is used by ordinary users
to send messages. For example, rmsg foo@bar hello there ! ^D would
send a message 'hello there !' to user foo at machine bar. By
default, rmsg stores the last outgoing message in the user's home
directory in the file .msgout. Then msg -r user@machine can be used
to resend the message. Message is normally read from standard input
until EOF.
Configuration:
--------------
The messages system has many options which the user can set by making
a file '.msgconf' in her home directory and placing various command in it.
Read the manual page for rmsg for more information.
//Jyrkiwcs) (05/11/91)
In article <kre.673801266@mundamutti.cs.mu.OZ.AU> kre@cs.mu.oz.au (Robert Elz) writes: > wcs@cbnewsh.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs) writes: > >* "mail" is for sending people messgaes with potentially structured > (and is irrelevant here) Not really - if somebody want's to reach me, they send mail, and an icon pops up on my screen at work, and a bell rings on my terminal at home. If I'm nearby, and don't mind being interrupted, I can reply. > >* "talk" is for coordinated real-time conversations between people, > >* "write" is for rudely interrupting people who haven't pre-arranged > I disagree with this .. both initiate conversations, both rudely > interrupt, the sole difference there is that with talk I cannot > see any hint of the other person's message until I respond, and > both have a very fixed interface style, that I can't alter. There are LOTS of talk programs out there. Admittedly, in the BSD world you've had sockets for 10 years, and probably all use the standard one, but here in the System V world we've used a variety of different talk programs. Some use sockets, some use files, some use FIFOs. Even in the BSD world, if you've got a workstation, you can use your own talk program instead of the standard one. > The interface we have does not require any pre-arrangement in order By pre-arrangement, I meant pre-arrangement between you and the system, like putting "biff y" or "message-widget -foo &" in your .profile. You do need to find out what flavor of talk-program somebody uses, but that can be resolved by directories or finger, or by mentioning it in your "Please call me" mail. > Unless you have operated in an academic environment with lots of > moronic undergrad students you may not appreciate the usefulness of > selective message control - I don't want to prevent messages from I used to always use "mesg y", but now that I'm in a window environment (and to some extent even when I'm using a screen editor) write and wall messages tend to get lost in the shuffle - maybe the bell gets through. People can always send me mail, and mail makes it easy to pick out useful stuff. One option with vanilla write, by the way, is to make your terminal group-writable, with a group that your friends are in and the annoying undergrads aren't :-) > in any case, the point is that its up to the user to decide just how, > and when, if at all, he wants to be interrupted. Agree with you there. -- Pray for peace; Bill # Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ # I never wanted to be a hacker! I wanted to be --- a lumberjack!
jmsellens@watdragon.waterloo.edu (John M. Sellens) (05/14/91)
In article <1991May5.130228.6320@santra.uucp> jkp@cs.HUT.FI (Jyrki Kuoppala) writes: |In article <kre.673344580@mundamutti.cs.mu.OZ.AU>, kre@cs (Robert Elz) writes: |[ describes a zephyr-like / write-like system on which you can control | the appearance of the arriving message ] | |I did something like that when getting familiar with SunRPC. It's a |bit buggy, but the idea is basically the one you're after, I think. |Also, it appears that SunRPC is not very good for this so the program |should be rewritten to work on top of a tcp protocol (funny, when it |was just an exercise in SunRPC to start with ;-). | |Here's the README file; the package is in nic.funet.fi, |pub/unix/tcpip/rmsg.tar.Z. If anyone is willing to adopt it and make |it better, feel free. At Waterloo, we have a command called (predictably) "msg", which seems very similar to Jyrki's "rmsg", except that it uses ordinary TCP/IP, rather than RPC. Runs on Sun Sequent MIPS DEC etc. We like it much better than write and talk, and have been using it for years, all over campus. Available via anonymous ftp from watmath.waterloo.edu in ~/pub/msg.shar and here's a copy of the man page for thoe of you who mght be interested. John MSG(1) User Commands MSG(1) NAME msg - write a short message to other users SYNOPSIS msg [ -l ] [ -m message ] [ -p ] [ -r ] user ... DESCRIPTION Msg writes a one-line message to a given set of users. If a user is logged in more than once, each instance of that user will receive the message. Previous versions of msg allowed the last argument to be the message. This confusing behaviour is no longer available. The message is preceded by a beep, the login name of the sender, and the name of the sender's machine. If the sender is set-userid to someone other than the super-user, then the real (set-userid) name is printed in parentheses. Replies should use the login name, not the parenthesized (set- userid) name, since the login name is the way msg finds peo- ple. Msg works across machines, as long as the remote machine is running the msgd(8) message daemon. To do this, user should be of the form person@machine (or the old-style machine!person ). It is very annoying to receive a message just before your screen clears, making it impossible to read the message. To help alleviate this problem, msg will save a copy of the message and you can use the -l option to repeat the last message you received. OPTIONS -r If the -r, option is given, msg will look in the file /usr/tmp/msg.userid file to find out the last person who sent you a message, and assume you want to reply to them. (Additional recipients can still be speci- fied, so the same rules apply about which arguments are messages and which are users. The easiest thing to use is msg -r with no other arguments; type the reply on the next line.) -l List the last message received. This simply shows the file /usr/tmp/msg.userid so that you don't have to remember the name. msg -lr is a handy way to show the last message and prompt for a reply. -p Use the text of the previous message you sent (saved in the file /usr/tmp/pmsg.userid) as the text of this message. This is handy if you mistyped someone's userid, and typed a long message only to have it Formatted 91/03/08 University of Waterloo 1 MSG(1) User Commands MSG(1) fail. Msg obeys the restrictions of mesg(1). SEE ALSO write(1), mail(1), talk(1), msgd(8) EXAMPLES % msg -m 'This is the message in quotes.' user1 user2 Quoting a string makes it one argument as far as Unix is concerned. % msg user1 user2 <type the message here, on the next line> % msg -r <Type a reply here to the last person who sent you a msg.> % msg -r -m 'Or you can put the reply here.' FILES /usr/tmp/msg.userid Contains the last message received. /usr/tmp/pmsg.userid Contains the text of the previous message sent or attempted. /usr/tmp/mesg.userid Answerback message - set by mesg(1). AUTHOR The staff of the Math Faculty Computing Facility at the University of Waterloo, Waterloo, Ontario Canada. Bug reports can be sent to either or both of John Sellens (jmsellens@watmath.waterloo.edu) or uw.mfcf.bugs@watmath.waterloo.edu. COPYRIGHT Copyright 1988, 1989, 1990 University of Waterloo Redistribution is permitted. Formatted 91/03/08 University of Waterloo 2