Subject: Re: tty0?
To: NetBSD <firstname.lastname@example.org.UnB.br>
From: Greg A. Woods <email@example.com>
Date: 06/24/1996 23:21:30
[ On Mon, June 24, 1996 at 22:55:01 (-0300), firstname.lastname@example.org wrote: ]
> Subject: Re: tty0?
> Tell this to the guys at BSDI. I am quite sure they DO understand what
> multi-user, multi-processing systems are!
The BSDI folks have been known to put only three legs on the corners of
a square table before because of customer demand. The customer is not
always right, but when he's paying you let him think so. I hope the
"free" *BSDs never fall into that trap.
Now, I'm not saying this particular case matches the scenario I paint.
In fact you've not described exactly what's happening at a sufficient
level of detail to know what's going on here.
Perhaps you are mistaken and are really thinking of the BSDI-1.1
'-D' extension to the stty command:
-D Display or set the system default settings rather than those for
the current device. The system defaults are used when a device
is initially opened. The system defaults may be set only by the
I've only access to BSDI-1.1 kernel source (i.e. not stty(1)), so I'm
not sure exactly how this is accomplished. The tty subsystem in
BSDI-1.1 is quite a bit different in some respects to the NetBSD one,
and I can't quite see where it might be setting and storing these
defaults. The kernel source seems to ignore <sys/ttydefaults.h> too,
except in one driver (si).
> By the way, if your program is to be portable, and you know that some
> systems reset to a known default state on open and others don't you'll
> end up writing code to reset a tty to a known state, to be sure it works
> on both. The same code would also work on a machine with run-time
> changeable defaults, of course.
Well, yes, to a certain degree. Some programs aren't quite so careful
as to completely reset all possible values to a known state, and indeed
may not be aware of some extensions available on some systems. These
are the cases where stuck, invisible, state is most horrible.
> I tend to agree with Bill most of the time. Why not add the flexibility
> of changing the defaults at run-time? If someone wants to be sure that
> the system is on a predetermined state, just change it to that state. You
> would have to open and close the device to be sure, anyway.
I didn't disagree with the concept of allwoing the default state to be
set, and given what the BSDI-1.1 manual pages suggest, this would be an
extension to the POSIX standard:
The stty function is expected to be IEEE Std1003.2 (``POSIX'') compati-
ble. The -e and -D options are extensions to the standard. The slip,
tty and flushout keywords are extensions to the standard.
In this case I would suggest following BSDI's lead.
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>