From owner-freebsd-current  Mon Mar 27 05:18:09 1995
Return-Path: current-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA08943 for current-outgoing; Mon, 27 Mar 1995 05:18:09 -0800
Received: from obiwan.pmr.com ([199.98.84.130]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id FAA08934 for <freebsd-current>; Mon, 27 Mar 1995 05:18:05 -0800
Received: by obiwan.pmr.com (Smail3.1.29.1 #4)
	id m0rtEff-00030WC; Mon, 27 Mar 95 07:17 CST
Message-Id: <m0rtEff-00030WC@obiwan.pmr.com>
From: bob@obiwan.pmr.com (Bob Willcox)
Subject: Re: tgetnum wierdness on -current
To: ache@astral.msk.su (Andrey A. Chernov Black Mage)
Date: Mon, 27 Mar 1995 07:17:26 -0600 (CST)
Cc: freebsd-current@freefall.cdrom.com
In-Reply-To: <bLPuaTlKE0@astral.msk.su> from "Andrey A. Chernov, Black Mage" at Mar 27, 95 09:33:13 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 2137      
Sender: current-owner@FreeBSD.org
Precedence: bulk

Andrey A. Chernov, Black Mage wrote:
> 
> Terminal entry can comes from various sources: /usr/share/misc/termcap
> ~/.termcap $TERMCAP f.e.
> To be shure just use one of the tests coming from lib/termlib/TEST,
> I think it is test1, compile it on -current with -ltermcap and
> run it on remote xterm. It just print out
> terminal entry, then seek li= there. If li=65, check various
> sources mentioned above, if all of them says li=24, there can be
> bug in tgetent, if all sources and output says li=24, there
> is bug in tgetnum.

Well, the termcap entry for xterm in -current does, indeed, specify
a line number of 65, so that is where the 65 is coming from and that
would seem to exonerate tgetnum.

> 
> >The application in question is files-2.2p1 that I am trying to port
> >to run on FreeBSD.  Whenever it receives a SIGWINCH signal it
> >terminates the current window by calling endwin() then reinstates
> >it by calling initscr().  It also calls wrefresh() for each of its
> >logical windows plus a number of other initializations.
> 
> It is right method when window changes.
> Please specify more detaily which ioctl failed in setterm().

It (the files program) does an endwin() followed by an

    ioctl(0, TIOCGWINSZ, &win_ws)

to get the new window sizes (which works). Then it does an initscr()
which calls setterm() which attempts an

    ioctl(STDERR_FILENO, TIOCGWINSZ, &win)

that fails.  setterm() then defaults to using the termcap values
for lines and columns.  The only significant difference appears to
be the file descriptor.  A file descriptor of 0 works, whereas, 2
does not.

Poking around a bit more in the source for files I see that it will
(under some circumstances that I have not yet nailed down) close
and reopen stderr.  Could this be the cause of the problem?  I
don't know stderr is opened to at the momemt (of the failure).
I will have to dig more into this.

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