9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Vadim Antonov avg@postman.ncube.com
Subject: More bugs.
Date: Thu, 17 Aug 1995 06:01:55 -0400	[thread overview]
Message-ID: <19950817100155.rmoryJZXv-gYb0SqV2zLlk3dCtVhlkIV8eg0RlqW-Bk@z> (raw)

>ohh no, rob has got it right with raw mode.  any other tty mode is
>a waste of time; just extra complexity for nothing.  this kind of
>thinking will result in a bsd-tty line discipline for plan9, job
>control, csh, dbx -- the horror, the horror...

Plan9 already has "line discipline" modules is several places
(devcons, 81/2, readln in auth utilities, telnetd), so instead
of replicating it would be useful to keep it in one place.

Raw mode and no echo mode are two different things and lumping
them together only makes all programs which read passwords
to be equipped with handling of kill and erase.

Most of the complexity of BSD and SysV line disciplines comes
from the history of the issue, as in v6 and v7 the hardware-specific
things were lumped together with the line discipline stuff.
Namely, ~ECHO had dual functon -- to handle half-duplex terminals
*and* to allow reading passwords.  Needless to say it was
inconvinient for both :)  RAW was "both ways", meaning no
conversion on output to terminals and no cooked processing
on input. That was very funny on terminals which needed 
output processing for things like Shift-In and Shift-Out
(yes, Virgina, there are people who speak funny languages
with letters like ya and tvyordyi znak).

For the hack value -- "no echo" on half-duplex hardcopy terminals
means typing over many times.  To my knowledge unix never
did that right.

If you don't like line disciplines you'd better not do
telnet-ing around.  There are different things (even TTYs)
on the Internet.  I respect the "simplicity is beauty" maxim
but tins on a string are arguably simplier than telephone.

Much of ugliness of present-day unices comes from the
under-functionality of the original system.  The holes were
plugged by other people, differently, and so the Babylon
started.  Later, some sorely misguided souls tried to "unify"
things by getting all variances into one system instead
of redesigning things to provide clear separation of functions.

Providing no functionality is not an answer, as people who
need to solve real problems in the real life will find ways
around it -- but it won't be pretty.  Not at all.

--vadim
(kremvax? yes, i used to run _the_ kremvax).






             reply	other threads:[~1995-08-17 10:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-08-17 10:01 Vadim [this message]
  -- strict thread matches above, loose matches on Subject: below --
1995-08-18  1:15 Boyd
1995-08-17 23:52 Boyd
1995-08-17 11:22 Vadim
1995-08-17  6:47 Vadim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19950817100155.rmoryJZXv-gYb0SqV2zLlk3dCtVhlkIV8eg0RlqW-Bk@z \
    --to=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).