Very Computer

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.

--


 University of Helsinki, Finland   ..!mcsun!uhecs!kankkune   (UUCP)

tgoto.

Quote:> 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).
--

+1 713 274 5180.  'U`  "Have you hugged your wolf today?"

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).

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.

Quote:> Newsgroups: comp.unix.programmer

Now if this was comp.unix.sysv386 you might have a point.

Quote:> 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.

Quote:> 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.
--

+1 713 274 5180.  'U`  "Have you hugged your wolf today?"

Thanks for your answers. I asked:

Quote:> 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,

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...).

 University of Helsinki, Finland   ..!mcsun!uhecs!kankkune   (UUCP)

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.
--

+1 713 274 5180.  'U`  "Have you hugged your wolf today?"

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.

Quote:>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()".

Quote:>> 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!
--


| | | | |_)  /_)    |  __/_) | (___\ | (_/ |  J. M. Gerard, Div. DD, CERN,
| | |_|_| \_/\___   \__/ \___|   (_|_|   \_|_ 1211 Geneva 23, Switzerland

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).

Quote:>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,*, and Harriet can "add" new
capabilities to "termcap" isn't an unmixed blessing....

("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.

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

Quote:>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.

Quote:>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,*, 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.

Quote:>("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?
--


| | | | |_)  /_)    |  __/_) | (___\ | (_/ |  J. M. Gerard, Div. DD, CERN,
| | |_|_| \_/\___   \__/ \___|   (_|_|   \_|_ 1211 Geneva 23, Switzerland

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.