pyr4@psc90.UUCP (**** The Wizard ****) (02/20/90)
I have been working with the termcap commands (tgetstr) etc.
and have run into a snag. The problem is when using a vt100 terminal
things get a bit strange. Here is a sample of the code I am using.
tgetent(termbuf,term = getenv("TERM"));
SO = tgetstr("so",&capptr); /* start reverse mode */
SE = tgetstr("se",&capptr); /* end reverse mode */
sprintf(buffer,"%s%s%s%s","This is ",SO,"reverse video",SE);
printf("%s\n",buffer);
The output I get looks like:
This is 2reverse video2
^ reversed ^
-----------------
This is part of the vt100 termcap entry:
Note the 2's:
v v
so=2\E[7m :se=2\E[m
What I would like to know is are they there for some purpose? If
so what is it. I would also like to how to use tgoto and tputs if possible.
Thanx in advance.
| Ted Wisniewski UUCP: uunet!unhd!psc90!pyr4 or: dartvax!psc90!pyr4|
| Plymouth State College |
| Plymouth NH, 03264 If I spoke for PSC they would pay me,|
| But instead I pay them. |gwyn@smoke.BRL.MIL (Doug Gwyn) (02/23/90)
In article <1177@psc90.UUCP> pyr4@psc90.UUCP (**** The Wizard ****) writes: > This is 2reverse video2 > so=2\E[7m :se=2\E[m > What I would like to know is are they there for some purpose? If >so what is it. I would also like to how to use tgoto and tputs if possible. There are two parts to your problem. The minor one is that some turkey has given you a bogus VT100 termcap. The VT100 absolutely must use DC3/DC1 flow control for proper operation; if the termcap description is properly set up, there is no need for the padding specifications (which is what the "2"s are). The major problem is that termcap string capabilities are designed to be output only by tputs() or tgoto(), which know how to handle all the relevant termcap conventions. You should not attempt to simply printf() the capability strings. This will be made clearer in the new revised termcap manual that I'm currently preparing, which will be posted somewhere and shipped off to Berkeley (with the intent that it be included in 4.4BSD) when it's ready. tgoto() and tputs() should be described under TERMLIB(3X) in your UNIX manual, and termcap is explained under TERMCAP(5) or TERMCAP(4), depending on whose manual section numbering system you're afflicted with.
hutch@fps.com (Jim Hutchison) (02/24/90)
In <1177@psc90.UUCP> pyr4@psc90.UUCP writes: > I have been working with the termcap commands (tgetstr) etc. ... > sprintf(buffer,"%s%s%s%s","This is ",SO,"reverse video",SE); ... > The output I get looks like: ... > This is 2reverse video2 > ^ reversed ^ > ----------------- >This is part of the vt100 termcap entry: >Note the 2's: > v v > so=2\E[7m :se=2\E[m The 2's are for padding (2 characters worth). You can either decode the padding yourself (which is what tputs will do for you, based on the "number of lines effected"). Reminds me of my old Ann Arbor 4080 which had to have 12 null pads following a "clear screen" at 2400 baud, in order to behave nicely. You can pad with any character appropriate to your terminal, although I've only every seen Null used as a pad. Null will certainly work for most vt100-clones. Nutshell publishes some nice pocket books on the subject of curses/termcap, including GNU extensions. You may want to consider picking up a copy as they are less confusing that the section 3 and 5 manual pages. The books are also somewhat more complete in their explanation of *how* to use things. -- /* Jim Hutchison {dcdwest,ucbvax}!ucsd!celerity!hutch */ /* Disclaimer: I am not an official spokesman for FPS computing */
bill@bilver.UUCP (Bill Vermillion) (02/25/90)
In article <1177@psc90.UUCP-> pyr4@psc90.UUCP (**** The Wizard ****) writes:
->
-> I have been working with the termcap commands (tgetstr) etc.
-> and have run into a snag. The problem is when using a vt100 terminal
-> things get a bit strange. Here is a sample of the code I am using.
->
->
-> tgetent(termbuf,term = getenv("TERM"));
->
-> SO = tgetstr("so",&capptr); /* start reverse mode */
-> SE = tgetstr("se",&capptr); /* end reverse mode */
->
-> sprintf(buffer,"%s%s%s%s","This is ",SO,"reverse video",SE);
-> printf("%s\n",buffer);
->
-> The output I get looks like:
->
-> This is 2reverse video2
-> ^ reversed ^
-> -----------------
->This is part of the vt100 termcap entry:
->
->Note the 2's:
-> v v
-> so=2\E[7m :se=2\E[m
->
-> What I would like to know is are they there for some purpose? If
->so what is it. I would also like to how to use tgoto and tputs if possible.
->Thanx in advance.
The numbers following the equal sign and before the actual escape sequence are
used for padding (delay).
I have found that in many distrubutions of termcaps that someone has put a
delay string in places that do not accept delay strings. I have found this in
some SCO termcaps, along with some graphics character reversals.
In the FM neither se nor so are permitted to have padding characters. This
caused me some grief before I went though the termcap an attribute at a time.
This seems to be done in many places. I just grep'ed the termcap file for any
"so=2" occurances and just found 10! Take out the "2"s after the = on the
above and your problem should go away.
bill
--
Bill Vermillion - UUCP: uunet!tarpit!bilver!bill
: bill@bilver.UUCPgwyn@smoke.BRL.MIL (Doug Gwyn) (02/25/90)
In article <7013@celit.fps.com> hutch@fps.com (Jim Hutchison) writes: >... (which is what tputs will do for you, based on the "number >of lines effected"). affected. Anyway, no it won't, because the affected-lines count is used by tputs() only when the padding specification in the capability string is immediately followed by an asterisk. >... You can pad with any character appropriate to your terminal, >although I've only every seen Null used as a pad. Null will certainly >work for most vt100-clones. NO, this is not how to determine the padding character. If the "pc" string capability is specified, use its value for the padding (should normally be just one character); otherwise assume NUL and nothing but NUL for the padding character. Remember, the whole point of termcap is to avoid wiring terminal- specific assumptions into applications!
gwyn@smoke.BRL.MIL (Doug Gwyn) (02/27/90)
In article <500@bilver.UUCP> bill@bilver.UUCP (Bill Vermillion) writes: >In the FM neither se nor so are permitted to have padding characters. Actually, that's an oversight that should be fixed in the updated termcap manual that I'm working on. All output string capabilities are allowed to have padding. The real problem is that only tputs() and tgoto() should be used to output string capabilities, not printf().