Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!caip!clyde!cbatt!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!convex!ndm20.UUCP!lvs
From: lvs@ndm20.UUCP
Newsgroups: net.unix
Subject: Re: tgetstr on system V R2 (HELP!)
Message-ID: <29000001@ndm20.UUCP>
Date: Mon, 21-Jul-86 15:32:00 EDT
Article-I.D.: ndm20.29000001
Posted: Mon Jul 21 15:32:00 1986
Date-Received: Fri, 25-Jul-86 07:02:39 EDT
References: <172@mtsbb.UUCP>
Lines: 59
Nf-ID: #R:mtsbb.UUCP:172:ndm20.UUCP:29000001:000:2372
Nf-From: ndm20.UUCP!lvs    Jul 21 14:32:00 1986



>    I am trying to get a recently posted reminder program (rs)
>to run on my machine (VAX 11/780 running Sys V R2).  The program
>seems to run okay, except that all calls to tgetstr() do not
>return the correct escape sequence (they return null).
>
>    The sequence being used is:
>	tgetent(bp, terminal name)  /* works fine - return of 1 */
>	tgetnum("co")		    /* works fine - returns 80 */
>	tgetstr("so",&some_buffer) or
>	tgetstr("bl",&some_buffer) or anything else
>				    /* returns 0's in buffer */
>
>    Does anyone know why it doesn't?  Am I doing something wrong?
>Please respond via email.
>
>Lee Vallone		AT&T Information Systems	Merlin
>{... ihnp4, mtuxo}!mtsbb!lav

No, you are not doing anything wrong, AT&T is!  They  have broken the
way  tgetent  and  tgetstr  work.   The only  help you  get from AT&T
software support is "Sorry,  we don't  support termcap  anymore".  Oh
well, so it goes.

The original definition for tgetstr was

   char *tgetstr( char *code, char **bufptr )

tgetstr would  get the  string you  desired (if  it can  find it) and
place it in your buffer, supplied  by bufptr.   It  would then update
bufptr  to point  just beyond  the string  just added  and return the
original value  of the  buffer pointer  (unless the  code couldn't be
found in which case it returns NULL).

Well, so much for the way it  SHOULD work.   The  version supplied by
AT&T in SVR2 is just plain broken.  It  does nothing  with the buffer
you supply  it, nor  does it  update the  pointer.   The only usefull
information is the return value.  If it is not NULL it  will point to
the string you requested.  Therefore, you must save  the return value
from the call, that is you can't use bufptr because  it doesn't point
to the string.  If you want the strings in a buffer you  will have to
copy them into it yourself.

Alas, it seems AT&T has broken termcap and instead of fixing it, they
decided not to support it.

BTW, the machine I have checked this  on is  an AT&T  PC6300PLUS.  It
exibited the same problems you described.  It  now works  by doing it
the way I described above.

Hope this helps,
Larry V. Streepy Jr.                        "Waiting is"
Nathan D. Maier Consulting Engineers

VOICE:  (214)739-4741
Usenet: {seismo!c1east | cbosgd!sun | ihnp4}!convex!infoswx!ndm20!lvs
CSNET:  ndm20!lvs@smu
ARPA:   ndm20!lvs%smu@csnet-relay.ARPA