Bug 174498 - ncurses return to filter mode will reset (clear) screen after term resize
ncurses return to filter mode will reset (clear) screen after term resize
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: ncurses (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Raszyk
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-29 10:46 EST by Erik Petrini
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: ncurses 5.4 Release 22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-01 09:32:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Example of resize clear problem, without SIGWINCH handling. (1.68 KB, text/plain)
2005-11-29 10:48 EST, Erik Petrini
no flags Details
'example of resize clear problem with some (naive?) SIGWINCH handling (2.40 KB, text/plain)
2005-11-29 10:51 EST, Erik Petrini
no flags Details
ncurses-5.4-22.src.rpm (2.01 MB, application/x-rpm)
2005-12-01 09:31 EST, Petr Raszyk
no flags Details

  None (edit)
Description Erik Petrini 2005-11-29 10:46:00 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)

Description of problem:
When running an application in filter (one line) curses mode a screen reset will occur when returning after temporary exit from curses mode IF a terminal resize has occurred (xterm tested, others probable). Problem is persistent after first resize.

Problem is same whether SIGWINCH is managed by app or not.
Problem cannot be resolved with resizeterm().
No workaround except not resizing the terminal found.

Curiously KEY_WINCH is set at return to to curses mode even though resize event was handled several getch():s before exit.

Note, if run with ncurses-5.4-20 unpatched, the clearing of the screen will probably take place regardless of resizing, see Bug #2966.

Version-Release number of selected component (if applicable):
ncurses-5.4-20   (patch 5.4.20050122)

How reproducible:
Always

Steps to Reproduce:
1. Compile and run attached clrexample or clrexample_small in an xterm window
2. When promted, change window size.
3. Step through rest of program
  

Actual Results:  The last row of output is at top of terminal window which has been cleared.

Expected Results:  The last row of output should be one row below previous output. (Which will happen if no resize is performed.)

Additional info:

Trial example was run on:
xterm -version  =>  X.Org 6.7.0(192)
gcc -v => gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3) (bug reproduced with intel compiler too)
Comment 1 Erik Petrini 2005-11-29 10:48:15 EST
Created attachment 121588 [details]
Example of resize clear problem, without SIGWINCH handling.

Small example to exemplify bug.
SIGWINCH handling is left to the internal handler.
Comment 2 Erik Petrini 2005-11-29 10:51:52 EST
Created attachment 121590 [details]
'example of resize clear problem with some (naive?) SIGWINCH handling

An attempt to work around the problem by catching the resize terminal and
resizeterm():ing the window. This file returned a KEY_WINCH on the final getch
call for a resize during the second getch call(!)
Comment 3 Petr Raszyk 2005-11-30 11:37:51 EST
Thanks for your investigation and examples.

This will be my first step tomorow.
Comment 4 Petr Raszyk 2005-11-30 11:41:03 EST
tomorrow (not tomorow)
Comment 5 Petr Raszyk 2005-12-01 09:31:59 EST
Created attachment 121687 [details]
ncurses-5.4-22.src.rpm

Fixed in current release.
Your examples work fine.
Please, can you compile and test *.src.rpm above ?
Comment 6 Erik Petrini 2005-12-01 10:05:33 EST
OK, will try ncurses-5.4-22 and get back to you.
Comment 7 Erik Petrini 2005-12-02 06:11:24 EST
With ncurses-5.4-22 everything works as expected.
Great job, thanks!
Comment 8 Petr Raszyk 2005-12-02 06:37:51 EST
And I thank you for your examples describing precisely the issue above.

Note You need to log in before you can comment on or make changes to this bug.