vances@xenitec.on.ca (Vance Shipley) (12/18/90)
Here's one for you terminfo gurus. I have an AT&T 5620 terminal and I am using SCO ODT. The problem is that when I log in the terminal reset escape code is sent and this seems to take two or three seconds to proccess in the terminal, by that time the string that declares the terminal type and sometimes the first "1%" are missed. I need to introduce a delay after the rs1 sequence. I tried adding a pad to the rs1 string but that didn't work because the npc boolean is present (no pad character). Removing npc and supplying a pad in rs1 results in garbage being displayed (the pad chars). How can I delay further action after the rs1 sequence? Why does terminfo use padding characters anyway, why not just wait? Vance Shipley vances@xenitec.on.ca.UUCP
pdk@pyrnj.uucp (Paul Kramer) (12/19/90)
In article <1990Dec17.171335.4861@xenitec.on.ca> vances@xenitec.on.ca (Vance Shipley) writes: > > How can I delay further action after the rs1 sequence? I will take a guess that this is being invoked with a `tput init`. If there is some non-printing & non-control character which could be amassed in a file, you could assign the "rf", (r)eset (f)ile, string in a new terminfo file like this: "rf=/usr/bin/my_dummy_data". Place as many characters in there as is necessary to produce the delay. If it is defined, the "rf" named file's contents get sent to the terminal during an initialization, right after the "rs2" string is processed. Alternately, you could move the completed escape sequence that is defined by "rs1" to a commands file. Then define the file name in the terminfo entry using the "iprog" capability. "iprog" is a way for terminfo to call an executable to do specialized terminal setup commands. This could be a 'C' or shell program. In the initialization program, one could send out the appropriate escape sequences, interspersed with sleeps for whatever duration necessary. Remember that this program is the first capability that is expressed when `tput init` is called, so you may want to change or re-arrange the other initialization strings (is1, is2, if, is3, rs1, rs2, rf, and rs3). If you need more information, look in the Programmer's Reference Manual at terminfo(4). It could prove illuminating. cheers, paul davis kramer
berny@tndsyd.oz (Berny Goodheart) (12/24/90)
In article <1990Dec17.171335.4861@xenitec.on.ca>, vances@xenitec.on.ca (Vance Shipley) writes: > Here's one for you terminfo gurus. I have an AT&T 5620 terminal and > I am using SCO ODT. The problem is that when I log in the terminal > reset escape code is sent and this seems to take two or three seconds > to proccess in the terminal, by that time the string that declares the > terminal type and sometimes the first "1%" are missed. I need to > introduce a delay after the rs1 sequence. I tried adding a pad to the > rs1 string but that didn't work because the npc boolean is present (no > pad character). Removing npc and supplying a pad in rs1 results in > garbage being displayed (the pad chars). > > How can I delay further action after the rs1 sequence? > > Why does terminfo use padding characters anyway, why not just wait? > Here is an excerpt from my book "UNIX Curses Explained": Initialization --------------- (is2): Essentially, the sequences for initializing the terminal are sent by the UNIX command tput. The command "tput init" should be issued before any program that uses terminfo (including curses). Ideally, this command should be run from your .profile at login time. The purpose of these initialization strings is to set up the terminal so that it is ready for use with curses or terminfo-based programs. Once transmitted to the terminal, they should place it into its relevant operating modes, which are consistent with the rest of the terminal's terminfo description. Generally, is2 is the most common string used for initializing the terminal. The command "tput init" does the following: (1) If the capability iprog is defined (which should contain the full path name of a UNIX command), then the program specified in this string is executed. This may be a special case program which initializes the terminal in a way that terminfo can't. Although this facility exists, there are currently no terminals in the terminfo database that use it. (2) If is1 is defined, this is sent to the terminal followed by is2. (3) Tabstops are initialized using tbc and hts. (4) If "if" is defined, the contents of this file are sent to the terminal. (5) Finally, the sequence for is3 is sent, if it is defined. (if): If the terminal initialization sequence is too long to fit in the description file, it should be put in a file which will be printed (sent) to the terminal. Thus, this string capability contains the full path-name of a UNIX file. It is normal for terminals that use this method to store their initialization files in the /usr/lib/tabset directory. (iprog): This string sequence contains the full path-name of a UNIX executable which is used to initialize the terminal (see above). (is1): This string contains the primary initialization sequence (see above) which may be used in special cases. (is3) This string contains the final initialization sequence (see above) which may be used in special cases. Resetting the terminal ------------------------ (rs2): As with the initialization capabilities, these strings are usually used to reset the terminal to a "sane" operating mode if it gets into an unusable state. This often happens if a curses program exits abnormally without calling endwin(). Normally, these strings are sent to the terminal by the UNIX command "tput reset" which leaves the terminal in a completely sane mode. The command "tput reset" does essentially the same as "tput init" except that the rs1, rs2 and rs3 strings are also sent. (rf): If the terminal's reset string is too long to fit in the description file, then rf should define the full path-name of a UNIX file (normally in /usr/lib/tabset) which will be printed to the terminal. (rs1): This string contains the primary reset sequence (see above) which may be used in special cases. (rs3): This string contains the secondary reset sequence (see above) which may be used in special cases. Berny Goodheart .===========================================================================. | ACSnet: berny@tndsyd.oz UUCP: uunet!munnari.oz!tndsyd.oz.au!berny | | INTERNET: berny@tndsyd.oz.au DOMAIN: goodheart_berny@tandem.com | | PSMAIL: smtpgate @comm(berny@tndsyd.oz@munnari.oz.au) | TANDEM Computers Incorporated 76 Berry St, North Sydney, NSW, 2060, Australia
hansen@pegasus.att.com (Tony L. Hansen) (01/13/91)
In article <1990Dec17.171335.4861@xenitec.on.ca>, vances@xenitec.on.ca (Vance Shipley) writes: > Here's one for you terminfo gurus. I have an AT&T 5620 terminal and > I am using SCO ODT. The problem is that when I log in the terminal > reset escape code is sent and this seems to take two or three seconds > to proccess in the terminal, by that time the string that declares the > terminal type and sometimes the first "1%" are missed. I need to > introduce a delay after the rs1 sequence. I tried adding a pad to the > rs1 string but that didn't work because the npc boolean is present (no > pad character). Removing npc and supplying a pad in rs1 results in > garbage being displayed (the pad chars). > > How can I delay further action after the rs1 sequence? If the terminal has no pad character, there is no way to introduce a delay instream within the terminfo sequence. I'm afraid that you don't have much recourse with the pad sequences $<n>, but will have to use something like the iprog to do the initialization. Even mandatory padding ($<n/>) doesn't help without a pad character. > Why does terminfo use padding characters anyway, why not just wait? The question is how? You need to do the output delay at the time that the sequence is output, which may be far removed within the program from when the output gets sent to the terminal. Tony Hansen att!pegasus!hansen, attmail!tony hansen@pegasus.att.com tony@attmail.com