Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Mar 1995 17:52:18 -0600 (CST)
From:      bob@obiwan.pmr.com (Bob Willcox)
To:        ache@astral.msk.su (Andrey A. Chernov, Black Mage)
Cc:        freebsd-current@freefall.cdrom.com
Subject:   Re: tgetnum wierdness on -current
Message-ID:  <m0rt26U-000300C@obiwan.pmr.com>
In-Reply-To: <kMPSVTlq_7@astral.msk.su> from "Andrey A. Chernov, Black Mage" at Mar 27, 95 03:22:01 am

next in thread | previous in thread | raw e-mail | index | archive | help
Andrey A. Chernov, Black Mage wrote:
> 
> In message <m0rt0MS-000300C@obiwan.pmr.com> Bob Willcox writes:
> 
> >On -current I have observed that tgetnum will *always* return 65
> >for the number of lines when running in a remote xterm (running on
> >a 1.1.5.1 system w/XFree86 3.1.1).  A local xterm or the console
> >seems to be correct.  Is there a known compatibility problem between
> >-current and 1.1.5.1 with xterms or is it likely that I'm doing
> >something wrong?
> 
> I don't see any problem here, tgetnum("li") always return
> what exactly specified in termcap, nothing more.
> It is per-program task use ioctl to get window dims.

Except that here my xterm termcap entry specifies line number as
24, yet tgetnum("li") returns 65 when executed in a remote xterm,
regardless of window size or termcap setting.

On a related problem I'm having, the ioctl call in setterm() in
curses is failing on the second and subquent calls to setterm().
(This is why I saw the tgetnum("li") problem.)  It works ok the
first time, but resizing the window exposes the failure when the
application does another initscr().  The application (and curses)
then thinks the window has 65 rows and misbehaves accordingly.


-- 
Bob Willcox                ...!{rutgers|ames}!cs.utexas.edu!uudell!obiwan!bob
Austin, TX                                 or: @uudell.us.dell.com:obiwan!bob
512-258-4224 (home), 512-838-3914 (work)          or: obiwan%bob@uunet.uu.net



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0rt26U-000300C>