.plan

[Barry Margolin]

In article <474 at escom.com> al at escom.com (Al Donaldson) writes:
>The only solution I know to this problem, short of using terminals that 
>don't have such awful holes (unfortunately, the terminal designer and
>most users probably see this as a "feature" instead of a hole) is to disable 
>messages from other users to your terminal (e.g., "mesg n").

How would "mesg n" solve the problem with plan files containing these
control sequences (see the Subject line of your message)?  The only
general solution is to fix the OS so it doesn't send control sequences
except when the application really wants them.

>However, I am a little confused by the discussion about ANSWERBACK sequences
>by BA Badger (above reference) and Bruce Barnett <1966 at crdgw1.crd.ge.com>.
>As I remember, answerback sequences were used years ago in multidrop line
>protocols to determine if a terminal was online and ready to receive before 
>sending a message.

Answerbacks are also used by some systems to determine the type of
terminal.  Honeywell VIP terminals send an answerback that begins with
the model number, and many other terminals send unique answerbacks.
Multics sends an ENQ (ctl-E) to a terminal when it dials up to try to
automatically set the terminal type.  I think I've heard of Unix
utilities that try to do the same thing.

>		     Surely answerback is not used by UNIX for this purpose,
>so is the point that a nastygram can be stored in my terminal, triggered 
>remotely by echo'ing a ctrl-E to my terminal, with the nastygram getting 
>passed straight to my shell?   I apologize if this is obvious to others, 
>but I just want to be sure I understand the risk.

What difference does it make whether Unix normally uses answerbacks.
The point is that many terminals have settable answerbacks, and they
can be triggered to send them.  If you print out a file that contains
the answerback-setting control sequence followed by an ENQ, the
answerback will be transmitted as if you had typed it.

Barry Margolin
Thinking Machines Corp.

barmar at think.com
{uunet,harvard}!think!barmar