kankkune@cs.Helsinki.FI (Risto Kankkunen) (04/02/91)
What is the standard way to apply parameters to the termcap strings you have read with tgetent? After a quick browse through manuals I didn't find any functions that would take a string capability and some parameters and return a string where those % escapes were replaced with the parameters in the right form. Something like tgoto, but not tied to cm capability. -- Risto Kankkunen kankkune@cs.Helsinki.FI (Internet) Department of Computer Science kankkunen@finuh (Bitnet) University of Helsinki, Finland ..!mcsun!uhecs!kankkune (UUCP)
peter@ficc.ferranti.com (Peter da Silva) (04/03/91)
In article <12587@hydra.Helsinki.FI> kankkune@cs.Helsinki.FI (Risto Kankkunen) writes: > What is the standard way to apply parameters to the termcap strings you > have read with tgetent? tgoto. > Something like tgoto, but not tied to cm capability. tgoto isn't particularly tied to cm, that I recall, unless the terminal expects certain control characters that UNIX maps or eats (^J, ^D). -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
rli@buster.stafford.tx.us (Buster Irby) (04/03/91)
peter@ficc.ferranti.com (Peter da Silva) writes: >In article <12587@hydra.Helsinki.FI> kankkune@cs.Helsinki.FI (Risto Kankkunen) writes: >> What is the standard way to apply parameters to the termcap strings you >> have read with tgetent? >tgoto. >> Something like tgoto, but not tied to cm capability. >tgoto isn't particularly tied to cm, that I recall, unless the terminal >expects certain control characters that UNIX maps or eats (^J, ^D). WRONG ANSWER: tparm( str, p1, p2, p3, ...) is the proper way to instantiate strings with parameters. Also, tputs() is the method used to output non cursor positioning strings after instantiation. tgoto() is a special case and is only used for cursor positioning, which means that it is *very* tied to cm. This is all defined in the manual under curses(3x).
peter@ficc.ferranti.com (Peter da Silva) (04/04/91)
In article <1991Apr02.223345.15465@buster.stafford.tx.us> rli@buster.stafford.tx.us writes: > peter@ficc.ferranti.com (Peter da Silva) writes: > >In article <12587@hydra.Helsinki.FI> kankkune@cs.Helsinki.FI (Risto Kankkunen) writes: > >> What is the standard way to apply parameters to the termcap strings you > >> have read with tgetent? > >tgoto. > WRONG ANSWER: > tparm( str, p1, p2, p3, ...) > is the proper way to instantiate strings with parameters. Really. Termcap, termcap... let's see what the manual says: tgetent, check. tgetnum, check. tgetflag, check. tgetstr, check. tgoto, check. tputs, check. tparm... um... Not in Xenix/286, let's try System V.2... It's under "curses... termcap emulation". OK: tgetent, check. tgetflag, check. tgetnum, check. tgetstr, check. tgoto, check. tputs, check. tparm... um... Someone's swiped my V.3.2 manuals, but nm /usr/lib/libcurses.a shows there *is* an entry for tparm. So it showed up in V.3.2. After some digging, I found it in SunOS but not in BSD. Under the System V compatibility library. Yep, it's a V.3 thing. > Newsgroups: comp.unix.programmer Now if this was comp.unix.sysv386 you might have a point. > Also, > tputs() is the method used to output non cursor positioning > strings after instantiation. tgoto() is a special case and is > only used for cursor positioning, which means that it is *very* > tied to cm. It's used for expanding "cs", too, at the very least. > This is all defined in the manual under curses(3x). Whose manual? If you're using termcap in the first place, rather than terminfo or curses, portability is obviously a concern. In that case it behooves you to use the least common denominator. tgoto. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
kankkune@cs.Helsinki.FI (Risto Kankkunen) (04/04/91)
Thanks for your answers. I asked: > What is the standard way to apply parameters to the termcap strings you > have read with tgetent? Peter da Silva suggested using tgoto. I was a bit hesitated to use that as the (SunOS) manual page implies it might contain much special case handling for cursor addressing: char * tgoto(cm, destcol, destline) char *cm; tgoto() returns a cursor addressing string decoded from cm to go to column destcol in line destline. It uses the external variables UP (from the up capability) and BC (if bc is given rather than bs) if necessary to avoid placing \n, ^D or ^@ in the returned string. tgoto also takes only two parameters, but in my case that would be sufficient. Buster Irby pointed out that in the curses(3x) manual page there is the function tparm(str, p1, p2, p3, ...), which seems to be just what I wanted. I had glanced also the curses documentation, but I had missed this. However, like Peter da Silva notes, this is a system V routine, and for portability my best bet is to use tgoto (and hope the cursor addressing special code doesn't mess things up). I just wonder, why there wasn't a tparm-like function in every termcap library from the beginning (the code must essentially be there in tgoto...). Risto Kankkunen kankkune@cs.Helsinki.FI (Internet) Department of Computer Science kankkunen@finuh (Bitnet) University of Helsinki, Finland ..!mcsun!uhecs!kankkune (UUCP)
peter@ficc.ferranti.com (Peter da Silva) (04/05/91)
In article <12738@hydra.Helsinki.FI> kankkune@cs.Helsinki.FI (Risto Kankkunen) writes: > However, like Peter da Silva notes, this is a system V routine, and for > portability my best bet is to use tgoto (and hope the cursor addressing > special code doesn't mess things up). Reasonable hope. 90% of terminals these days use ANSI X3.64 sequences, and most of the remainder use ADM3a type sequences. Neither of these traditions involve the characters that mess up tgoto. I use tgoto to parse "cs" all the time, no problem. Yes, there are weird problems with termlib. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
dick@ahds.UUCP (Dick Heijne CCS/TS) (04/05/91)
In article <577@bria>, writes: > (...) > you could always switch to the *real thing* and use terminfo instead. :-) The only(?) disadvantage of this *real thing* is, that you can't introduce new entries, which is quite simple in termcap. So far, I didn't find any advantage of terminfo over termcap. After solving the two-character entryname limit of termcap by writing my own libtermcap.a (with a variable buffersize instead of the standard 1K and unlimited entryname-length) I keep prefering termcap over terminfo for its greater flexibility.
guy@auspex.auspex.com (Guy Harris) (04/06/91)
>tparm( str, p1, p2, p3, ...) > >is the proper way to instantiate strings with parameters. Also, >tputs() is the method used to output non cursor positioning >strings after instantiation. tgoto() is a special case and is >only used for cursor positioning, which means that it is *very* >tied to cm. This is all defined in the manual under curses(3x). Funny, there's *no* mention of "tparm()" in the "curses(3x)" on my machine. Of course, there *is* a mention of it in "curses(3v)". Remember, not *everybody* out there is running the same flavor of UNIX as you are. ("You" here meaning "any of you".) The BSD "termcap" library has only "tgoto()" for instantiating strings with parameters; the S5 "curses" library has "tparm()".
jmg@cernvax.cern.ch (mike gerard) (04/06/91)
In article <1931@ahds.UUCP> dick@ahds.UUCP (Dick Heijne CCS/TS) writes: >> you could always switch to the *real thing* and use terminfo instead. :-) >The only(?) disadvantage of this *real thing* is, that you can't introduce >new entries, which is quite simple in termcap. So far, I didn't find any >advantage of terminfo over termcap. After solving the two-character entryname >limit of termcap by writing my own libtermcap.a (with a variable buffersize >instead of the standard 1K and unlimited entryname-length) I keep prefering >termcap over terminfo for its greater flexibility. Exactly what I found. I wanted more efficient sequences to move right on the same line, so I put in a termcap entry of the form rt=\E[%dC: and then use it with tputs(tgoto(RT, nx-ox, nx-ox), 1, putchar); (where clearly nx = new x-value, ox = old x-value. There are other sequences that I wanted in termcap (how to switch between 80 and 132 column mode): the nice thing about termcap is to be able to do this without upsetting other uses. Another vote in favour of it! -- _ _ o | __ | jmg@cernvax.uucp | | | | _ / \ _ __ _ __ _| jmg@cernvax.bitnet | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. DD, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland
jim@segue.segue.com (Jim Balter) (04/07/91)
In article <12738@hydra.Helsinki.FI> kankkune@cs.Helsinki.FI (Risto Kankkunen) writes: >Peter da Silva suggested using tgoto. I was a bit hesitated to use that >as the (SunOS) manual page implies it might contain much special case >handling for cursor addressing: The SysV terminfo tparm() does the same special case handling. The special case handling is to deal with UNIX terminal driver peculiarities. SysV terminfo provides a tgoto() for compatibility with termcap. tgoto(cap, p1, p2) is exactly equivalent to tparm(cap, p2, p1) (note reversal of arguments).
guy@auspex.auspex.com (Guy Harris) (04/09/91)
>Exactly what I found. I wanted more efficient sequences to move right >on the same line, so I put in a termcap entry of the form > > rt=\E[%dC: Which might well be considered an argument in favor of *terminfo*. At least according to the SunOS 4.0.3 TERMCAP(5) manual page, and the 4.3-tahoe TERMCAP(5) manual page, the "RI" capability takes a single numeric parameter, and moves the cursor right that many positions - i.e., there's *already* a capability of the sort you wanted, but with a name *other* than the one you chose. Unfortunately, given that there's no single place that specifies what the complete set of valid capabilities (at least for any given OS release) are, it's easy for people to add them, ignorant of the fact that some programs might accept some *other* name for the same capability. The fact that every Tom, Dick, and Harriet can "add" new capabilities to "termcap" isn't an unmixed blessing.... ("terminfo", of course, already has an equivalent capability, namely "cuf".)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/10/91)
In article <7068@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > Unfortunately, given that there's no single place that specifies what > the complete set of valid capabilities (at least for any given OS > release) are, it's easy for people to add them, ignorant of the fact > that some programs might accept some *other* name for the same > capability. The fact that every Tom, Dick, and Harriet can "add" new > capabilities to "termcap" isn't an unmixed blessing.... Agreed. The natural solution is to have a special namespace for experimental or nonstandard capabilities. If it weren't for the two-character format I'd suggest names starting with X as free. With such a convention, termcap would resume its rightful place above terminfo in the hearts and minds of UNIX programmers. [1/2 :-)] ---Dan
dick@ahds.UUCP (Dick Heijne CCS/TS) (04/11/91)
In article <7068@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: > ("terminfo", of course, already has an equivalent capability, namely > "cuf".) You're absolutely right, but what if neither package covers your needs? The reason I decided to stick to termcap rather than terminfo was, that I had to write an alternative to curses, since the applications run on many different terminals, and also terminals with a specific emulation (i.e. vt220 or wyse50) from many different manufacturers, so all with different labels on the keyboard and sometimes with totally different keyboards. So, I added not only new entries but also new capabilities, by introducing a new type, i.e. the '%|' type. An example of such an entry is: :NX=\E[6~%|Next Scrn: which means that the logical "Next Screen" function is performed by the key that sends the \E[6~ sequence, and is labeled with the text Next Scrn. On the product of another manufacturer the text can be different or the sent sequence or both. The program, however only looks for the NX entry in order to perform its LOGICAL Next Screen function. This also worked out to be very useful in generating Help screens, which all show now the logical function of the specific application, next to the label of the button on the keyboard. And that is what they should display. This way, we ended up to remain totally independend of the creative minds of the various terminal manufacturers. As you notice I created lots of logical functions next to the physical ones in termcap. This ended out much more practical in programming applications. You can think of it what you like, but my programmers AND end-users like the results of it very much. All of this is absolutely impossible in terminfo. I hope I made myself a bit more clear. Regards, Dick.
jmg@cernvax.cern.ch (mike gerard) (04/11/91)
>At least according to the SunOS 4.0.3 TERMCAP(5) manual page, and the >4.3-tahoe TERMCAP(5) manual page, the "RI" capability takes a single >numeric parameter, and moves the cursor right that many positions - >i.e., there's *already* a capability of the sort you wanted, but with a >name *other* than the one you chose. Well, it does not appear in the parameters that my Ultrix system shows with man 5 termcap. There IS something called ch, which might or might be the same thing. However, the description does NOT specify "right" and the few entries in the /etc/termcap file are rather wierd and clearly not for standard ASCII terminals. I am delighted to know that there is some sort of standard for this sequence. >Unfortunately, given that there's no single place that specifies what >the complete set of valid capabilities (at least for any given OS >release) are, it's easy for people to add them, ignorant of the fact >that some programs might accept some *other* name for the same >capability. The fact that every Tom, Dick, and Harriet can "add" new >capabilities to "termcap" isn't an unmixed blessing.... It so happens that I am using these new inventions on systems over which I have total control: no-one logs in on them, though many people use them. The program that I distribute will also run if they are not defined. >("terminfo", of course, already has an equivalent capability, namely >"cuf".) But terminfo has nothing in there for switching between 80-column and 132-column mode (useful when emulating an IBM 3278-5): what would you suggest that I do there? I could also do with a sequence to set the cursor type (block/underline, blinking/unblinking). Doubtless other people have other ideas and needs: what should we all do if we only have terminfo? -- _ _ o | __ | jmg@cernvax.uucp | | | | _ / \ _ __ _ __ _| jmg@cernvax.bitnet | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. DD, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland
guy@auspex.auspex.com (Guy Harris) (04/16/91)
>Doubtless other people have other ideas and needs: what should we all do >if we only have terminfo? I didn't say the "terminfo" approach was necessarily the right one. I merely pointed out - correctly - that the flexibility you get from "termcap" is not an unmixed blessing (as you've already discovered, given your comment that 1) "RI" isn't in the manual for your Ultrix system and 2) the fact that there's this "ch" capability that doesn't quite look right)....
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/16/91)
As quoted from <4866@cernvax.cern.ch> by jmg@cernvax.cern.ch (mike gerard): +--------------- | But terminfo has nothing in there for switching between 80-column and | 132-column mode (useful when emulating an IBM 3278-5): what would you | suggest that I do there? +--------------- I defined rs3 as the name of the terminfo description to use for a "wider" version of the terminal, rs1 as the one for a "narrower" version, and is3 in each to be the string to set the terminal to the proper mode. +--------------- | I could also do with a sequence to set the cursor type (block/underline, | blinking/unblinking). +--------------- Look at the uses of civis/cnorm/cvvis. +--------------- | Doubtless other people have other ideas and needs: what should we all do | if we only have terminfo? +--------------- Gradually expand it to be useful *while arranging for compatibility*, as AT&T has been doing. Granted, it's a slow process, but I find that I only have to keep *one* terminfo description for a terminal, versus as many different termcaps as makers of programs that corrupt it in their own incompatible ways. (SVR3, SCO, Informix, Unify, MultiView, Progress, Uniplex, ... every single new program we get has a new termcap-variant, most of which can be folded into a single SVR3.2 terminfo entry with little or no loss of information.) Since I have to maintain all these things, having one *standard* terminal capability database format is exceedingly useful. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 2m, 220, 440, 1200 Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed) America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH