ncurses subwindow fails in 80x25 console

[gobo20@lycos.com]

I'm still wrestling with my ncurses terminal size. I have an app
with a 60x22 scrolling subwindow (i've changed the size all over the
place.) Everything seems to work fine using windows vt100 emulators,
as long as the window size is 80x26 or larger. Note the 26! When I
try to run this same app on the linux console (plain vga) the scrolling
subwindow won't work. I wrote a quick pgm that queries the terminal
and it reports 80x25. If is resize the win emulator to 80x25, I get
the same results as the linux console. I'm stuck; I don't get
where this 80x26 is coming from or how to change it. Perhaps I'm
confusing myself with the win emulator screen size, but i don't know
what i need to change to make this work on the console.

Thanks.

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

gobo20@lycos.com wrote:

> where this 80x26 is coming from or how to change it. Perhaps I'm
> confusing myself with the win emulator screen size, but i don't know
> what i need to change to make this work on the console.

A general procedure can be:

echo $LINES

Resize the window.

echo $LINES

If results are equal, the client or the serve you are using to have a shell
does nor propagate window resizing. Then your only option is to manually
set the LINES variable, and do not resize the window while running a curses
app.

--
Salu2

[Thomas Dickey]

Juli?n Albo <JULIANALBO@terra.es> wrote:
> gobo20@lycos.com wrote:

>> where this 80x26 is coming from or how to change it. Perhaps I'm
>> confusing myself with the win emulator screen size, but i don't know
>> what i need to change to make this work on the console.

> A general procedure can be:

> echo $LINES

> Resize the window.

> echo $LINES

> If results are equal, the client or the serve you are using to have a shell
> does nor propagate window resizing. Then your only option is to manually
> set the LINES variable, and do not resize the window while running a curses
> app.

not exactly. While it's possible for a shell to maintain the $LINES variable,
you should not assume that is the case.

The "stty -a" command would show the information you're expecting.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Thomas Dickey wrote:

>> If results are equal, the client or the serve you are using to have a
>> shell does nor propagate window resizing. Then your only option is to
>> manually set the LINES variable, and do not resize the window while
>> running a curses app.
> not exactly. While it's possible for a shell to maintain the $LINES
> variable, you should not assume that is the case.

Not in general, but talking about linux is safe enough to assume that people
use bash. And if not, that they know they must verify if your shell does
the same.

--
Salu2

[Thomas Dickey]

Juli?n Albo <JULIANALBO@terra.es> wrote:
> Thomas Dickey wrote:

>>> If results are equal, the client or the serve you are using to have a
>>> shell does nor propagate window resizing. Then your only option is to
>>> manually set the LINES variable, and do not resize the window while
>>> running a curses app.
>> not exactly. While it's possible for a shell to maintain the $LINES
>> variable, you should not assume that is the case.

> Not in general, but talking about linux is safe enough to assume that people
> use bash. And if not, that they know they must verify if your shell does
> the same.

Even for the specific case - there've been bug reports for bash in this area.
(And the assumption isn't that good either ;-)

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Thomas Dickey wrote:

>>> not exactly. While it's possible for a shell to maintain the $LINES
>>> variable, you should not assume that is the case.
>> Not in general, but talking about linux is safe enough to assume that
>> people use bash. And if not, that they know they must verify if your
>> shell does the same.
> Even for the specific case - there've been bug reports for bash in this
> area. (And the assumption isn't that good either ;-)

Haven't seen that bugs yet, I will take into account in the future.

--
Salu2