Re: menuconf

William E. Roadcap (
Wed, 25 Jun 1997 21:52:01 -0400 (EDT)

On Wed, 25 Jun 1997, A.E. Brouwer wrote:

I wrote:
> point is well taken, and I should probably modify that change. Perhaps a
> simple 'tput rs2' or something similar?
> Hmm - from man terminfo:
> Commands are normally placed in rs2 and rf
> only if they produce annoying effects on the screen

Obviously the BEST place to reset the terminal should be when Menuconfig
detects that lxdialog has failed, not preceeding a _normal_ exit as I have
done in the patch. I concede that I should move the reset (or tput rs2 or
whatever) to a more appropriate location.

Really, the more "correct" thing to do (IMO) would be to capture the
termio settings (stty -g) upon entry into the script. Then upon a failure
induced "bailout" exit, reset the terminal (rs2 or whatever) and restore
the previously captured termio settings.

> > On my machines rs2 is not defined for the Linux console.

Hmm, maybe it should be. From man terminfo:
A pair of sequences that does a harder reset from a
totally unknown state can be analogously given as rs1,
rs2, rf, and rs3, analogous to is2 and if. These strings
are output by the reset program, which is used when the
terminal gets into a wedged state. Commands are normally

If what you say, and the above excerpt is true, your /usr/bin/reset might
not be working properly.

> Think of it this way: If your program is correct it leaves the
> terminal in a good state.

No, no, no, NO. That is an unfair BLANKET statement that can only be true
in a "perfect" world. There are conditions that are beyond the control
of, me, you, Menuconfig or lxdialog which can cause lxdialog to fail and
leave the screen in a funky state. For example, mis-installed ncurses
libraries can cause lxdialog, and other programs, to segfault. Mixing
versions during upgrade is a common ncurses installation mistake. Other
external software and/or hardware problems could cause lxdialog to fail
without getting a chance to cleanup after itself. As well, a screwed up
terminfo or TERM definition could cause problems that are unrecoverable
even by /usr/bin/reset.

However, I think "good" is a relative concept in this context. I _AM_
trying to leave the terminal in a "good" state. IMO, good is the state
that is2 and/or rs2, along with a proper restoration of termio settings,
would leave the terminal.

> The program reset will bring a terminal
> from an unknown, undesired state to a tolerable state.

That's exactly why the "reset" needs to be there, and relocated, in the
script. However, if your terminfo definition has inadequate or absent is2
and/or rs2 entries, then a reset will AT BEST leave it in only a
"tolerable" state. Perhaps your terminfo definition should be enhanced to
reset your terminal properly so that it will be left in a correct or
better-than-tolerable state?

> If you invoke reset without good reason, just `to be sure',
> then you go from the correct state to a less correct but tolerable
> state. Not a good idea.

I half-heartedly disagree. First you assume the terminal was in a correct
state to begin with. Not always the case. Second, IMO, 'just to be sure'
IS a good reason. Your view of when it is proper to reset the terminal
seems very narrow to me. However, I think this is a relatively
unimportant argument over semantics. I think it's neither desireable nor
undesireable to place a "cover your ass" reset into a script. Especially
one which relies heavily on outside utilities to accomplish it's task.

I do feel it is wrong to uncategorically state that a program is buggy
simply because the author is attempting to leave things tidy.

William E. Roadcap
TITUS Software
Waynesboro, Va (USA)