> I am writing some sort of alarming utils run from within xterm only, ie
>won't work on non-xterm environment. What happen is that, when a scheduled
>event is activated at the right time, it will simple write a message to
>the xterm's header as title , blinking and beeping, and at the moment I
>resort to using escape sequence, ie : echo -n "]2;message" to change the
>xterm header border! Also, I am using cron to do the stuff since the system
>I run doesn't have at, but crond will direct any output of a scheduled
>program to a file and mail it to the user, as a result my escape sequence
>can not reflect the changes onto my xterm.
This is a bad thing in general.
First, the cron jobs can redirect their output to a particular terminals
fairly easily. You will want to not output to stdout unless you freopen()
it to the terminal you are interested in writing to.
The reason using "broadcast" escape sequences this way is a bad thing is
that you can not guarantee the current terminal state at the time of the
boradcast; this is primarily a problem with many applications (MS BASIC
for Xenix, for instance) which read the termcap themselves and output
the escape sequences themselves. Secondly, since output is flushed on
block boundries for most curses apps, there is no guarantee that curses
itself will attempt to guarantee atomicity. Finally, there is no
guarantee that the I/O will not be scheduled seperately within the tty
subsystem itself.
Boiled down, this means that you may send an escape sequence in the
middle of another program sending an escape sequence. If you want
to look at it another way, terminals (including xterm and your console)
are finite state automatons which start in the ground state; when they
see an escape sequence, they go into other states until they see the
terminal character in the sequence, after which they drop back to the
ground state. For a broadcast escape sequence to work:
(1) It must be sent only if the terminal is in the ground state
(not processing another sequence at the time).
(2) It must be I/O atomic -- that is, it must contain the start,
middle, and terminal character of the escape sequence, and
these must be written to the device in a single I/O operation.
VMS gets around this problem by having automatons that act like the
terminal itself in the driver, and then controlling the I/O libraries
and the types of terminals which will work on the machine. Then when
a second channel is opened to the device, I/O is blocked until the
internal automatons on the other channels are all at state 0.
A similar method is used in transparent printer drivers by Digiboard (I
don't know if other companies do this yet) to ensure print sequences and
data don't interrupt escape sequences from the terminal itself.
Anyway, you are looking at a lot more than simply "what to do with cron"
if you want broadcast escape sequences to work reliably.
Terry Lambert
---
Any opinions in this posting are my own and not those of my present
or previous employers.
by