Frank Van Der Linden writes:
> Implementing this is not hard, and is not really the issue. My issue:
> I've never really liked the info, printed from the kernel, that ctrl-t
> triggers by default. It is not that useful, and there are many other
> tools to look at that info in a less intrusive way. Also, implementing
> it this way changes the default behavior for the ctrl-t keystroke. This
> is perhaps not a major issue, since applications that do not want any
> surprises from keystrokes can only have that guarantee by disabling
> IEXTEN, and there might not be any applications at all that have a
> controlling terminal and that use ctrl-t for anything.
I think that if this exists at all, it should be a shell function.
Doing it from within ldterm feels like a horrible kludge.
> These are the options. For the sake of simplifying this list, I will not
> consider applications that do not to
> tcgetattr(cttyfd, &defaults); new = defaults ; modify new;
> tcsetattr(cttyfd, &new), but for example construct a termios structure
> by hand. These applications are broken, and I do not know of any that do
> this.
I don't think I'd call them "broken." I also don't see how they're
harmed as long as they do something reasonable, such as bzero the
array before setting.
> 4. VSTATUS is set by default. load + process info is never printed. The
> signal is sent.
> Pro: Default behavior not changed.
> Con: Not BSD behavior compatible, nor fully BSD source compatible
> (no NOKERNINFO)
I like this option best; it's cleanest. We can always add the kernel
hack^Wfeature and NOKERNINFO later if someone really wants it.
> I have read that OS X originally did something like 3, but on my 10.4.x
> system, it seems to have the full BSD behavior.
>
> I'm leaning towards 4 myself. It is the simplest, and optionally,
> NOKERNINFO could be defined as a dummy flag. 2 is my second choice.
I'm not sure if adding a "dummy" flag makes sense. It'd have to be
there for a really good reason -- like supporting an application that
does this:
#ifdef VSTATUS
flags |= NOKERNINFO;
#endif
Are there such applications?
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
opensolaris-code mailing list
[EMAIL PROTECTED]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
