Shell Programming and Scripting

Well, scripts and commands they can call, apparently.

One paradigm that might work for you is to have users drop comments as files in a dir, and have a daemon gor around polling all the comments and moving them to a common message file that is then extended on every host, where viewers are watching it with tail -f. More ssh/rsh than whatever.

A messaging milieu needs authentication, a directory service of discussions one can join, a means of viewing the discussion and a means of appending commetns to the discussion. You might extend it to having admins and chairpersons for better control. If discussions are long, each user should have a high water mark setting in every discussion so they can catch up. A facility for attachments like email is nice, too. Then there are things like abuse reporting, blocking, encrytption of records. It pays to envision with a very open mind.

This script can be much easier: Just a message should appear on the receiver's terminal. Depending on the user privileges, the message can be sent to only one or to all users. A simple chat is possible with netcat, but it has to be instantiated from both sides. Maybe it could be better done with rcp, but here some kind of event listener would be necessary.

Writing to the tty of another user usually has permission problems. If you have one window for the discussion, which is "tail -f mtg_file" and one for comments 'while read l ;do echo `id -un`": $l" >>mtg_file ;done' then all you have to worry about is file permissions and ssh if remote. You might what to use an xterm with a big scroll buffer and not set to return to the bottom on every output. Or you chould share a google drive doc.

Maybe my approach isn't optimal, but my shell scripting knowledge is only a couple of days old. I thought it could work like this:

Dispatcher:
Writes text into a file. The file is sent to the receiver by rcp command.

Receiver:
A process is running in the background that is waiting for incoming messages. When a message is detected, it's written on the console. The messages are stored in /tmp/var or /tmp.

Oddly enough, that approach sounds a lot like how an email originated. It could work. Polling is never efficient but if more sensible method are denied you nothing better pops to mind.

Do I have any better options in shell script than polling (while-sleep-construct)?

Polling is an architectural choice. If the originators have a subscription list or a common destination, they can push. Polling is about pulling information that may not exist yet. Then there are signals, which shells can send with kill and receive with trap. Two signals are reserved for app use. Signals allow for interrupt driven processing, which is a sort of push, in that the originator pushes a signal. The master can process signals one at a time so no chaos erupts. However, the signal is pretty bare, does not tell you who is calling, so you need a per sender message file, even as just a flag, that is only polled on interrupt. That's nicer than polling in a tight loop wasting and destroying resources, or sleeping and ignoring new data. There is often a little poll under an interrupt. You could have the message files be queued in a special directory, named uniquely, so on interrupt the master processes each and then deletes it. The file name or content may just tell the master where to go for the full message, or may be the full message. Files can be composed elsewhere on that file system or in that dir but with a filtering extension, and mv'd when complete, so there is no race condition. Directories provide all the necessary locking and list management for multiple simultaneous writers. Exploit them.