Date: Mon, 27 Mar 1995 07:17:26 -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: <m0rtEff-00030WC@obiwan.pmr.com> In-Reply-To: <bLPuaTlKE0@astral.msk.su> from "Andrey A. Chernov, Black Mage" at Mar 27, 95 09:33:13 am
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0rtEff-00030WC>