scs@hstbme.mit.edu (Steve Summit) (09/13/89)
Once upon the time, the "reset" command merely reset the terminal
driver to a sane state. That was its job; it concerned itself
with the tty driver, not the physical terminal; the man page even
said so, and suggested following reset with tset, resetting the
physical terminal being tset's job.
Then some (lost, misguided) soul decided that reset should fix
the physical terminal, too. It began checking $TERM, opening the
termcap file, sending the "is" sequence, etc.
This irritated me, because if TERM wasn't set right, I'd get
garbage on the screen. (When I log in briefly, or from a weird
terminal, or only in order to telnet, I don't always worry if
TERM is wrong if I won't be doing any full-screen editing, but I
still may have occasion to run "reset.") So, since I never had
any problem with the distinction between reset and tset, I put
the following "reset" shell script in my bin directory:
TERM=dumb /usr/ucb/reset $*
Today it started printing "type dumb unknown", because recently
I set $TERMCAP pointing at my own termcap file, which doesn't
happen to have a dumb entry. At the same time, it ceased to
correctly reset the tty driver, and I checked several other
alternatives first, never dreaming that the "type $TERM unknown"
error could be being considered fatal, and causing a premature
exit before getting to the ioctl part. In fact, this is
apparently the case.
FIX 1: Rip the physical terminal handling out of reset, leaving
it to tset, where it belongs.
Since that would doubtless be unpalatable to those who are used
to the present behavior, I offer
FIX 2: Arrange that the tty driver resetting happens even if the
physical terminal handling cannot.
For now, I'm both changing my shell script to
TERMCAP=/etc/termcap TERM=dumb /usr/ucb/reset $*
and adding a "dumb" entry to my personal termcap, but I think
reset's behavior should definitely be fixed.
(I just looked at the man page for reset, which I hadn't checked
for some time, and I find that tset and reset have apparently
been merged. So much for "each tool should do exactly one job,
and do it well." Could the "reset" entry to tset/reset maybe get
a new option flag meaning "just do the tty driver"?)
(I suppose since Berkeley invented reset in the first place, it's
their right to encumber it with tset functionality if they want to.)
Steve Summit