Messages in this thread | | | Date | Wed, 25 Jun 1997 21:52:01 -0400 (EDT) | From | "William E. Roadcap" <> | Subject | Re: menuconf |
| |
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.
Eddie __ William E. Roadcap mailto:roadcapw@titus.org TITUS Software ftp://ftp.titus.org/pub Waynesboro, Va (USA) http://www.cfw.com/~roadcapw
| |