Duplicating ASCII bel in the tty driver (was Re: Changing tty drivers)

[Boyd Roberts]

In article <CEDMAN.90Oct17195500 at lynx.ps.uci.edu> cedman at lynx.ps.uci.edu (Carl Edman) writes:
>
>Summary: I think it is a good and simple idea, which (in contrast
>to almost all other suggestions made in this group) actually
>would work.
>

No, no, no, no!  It may be simple, but it's just not _right_.
When you write ASCII bel to some file/tty/whatever you expect
to get _one_ ASCII bel.  Not two.  Just one.

It's just a YANDS (Yet Another Nickel and Dime Solution).  A proposal
to break the tty driver for no good reason, except that it's cheap.

Consider a communications protocol that runs across RS-232 via the
tty driver.  This protocol uses full 7 bit ASCII (or 8 bits if you like).
Every once in a while it is _possible_ that an ASCII bel may appear
in the byte stream of this protocol (maybe a real bel, maybe ASCII 7
makes up part of a CRC checksum).  And at this point another bel is
inserted, corrupting the protocol which will result in circuit shutdown. 

At this rate every second ASCII character will have to have special
escapes built in to avoid broken tty drivers.  There could be a
`character of the day' so that each day a _different_ character would be
duplicated.  Why stop there?  Why not have some magic cursor orientated goo
which gets inserted to display some dinky little icon...  Where will it end?

In the back of my mind I can see the tty driver being hacked so
that two bel's on input become one, so broken tty drivers can
talk to each other.  Even worse, there could be an stty mode
that turns this input mapping on and off.  But, I won't think
about that too hard...

With design like this, who needs bugs?


Boyd Roberts			boyd at necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''