Bug 2966 - getch() clears screen
Summary: getch() clears screen
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: ncurses
Version: 3.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Petr Raszyk
QA Contact: David Lawrence
Depends On:
Blocks: 170445
TreeView+ depends on / blocked
Reported: 1999-05-22 14:50 UTC by ppe
Modified: 2007-11-30 22:06 UTC (History)
1 user (show)

Fixed In Version: ncurses 5.4 Rel.19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-11-07 15:04:00 UTC
Target Upstream Version:

Attachments (Terms of Use)
rpm package (2.01 MB, application/x-rpm)
2005-09-30 13:35 UTC, Petr Raszyk
no flags Details

Description ppe 1999-05-22 14:50:36 UTC
This is a strange bug: When I run 'undelete' from the
'safedelete' package, the menu screen flashes up only
to become erased immediately. I traced it to the point
where 'undelete.c' does:

/* Get input from the user and process it */

Well, when 'getch' is called, the screen goes black. It
happens in an xterm and on the text console.

Redhat 6.0

Comment 1 Preston Brown 2000-05-05 16:10:59 UTC
this seems to be a bug in undelete's code, and not in ncurses.

Comment 2 Erik Petrini 2005-08-31 09:28:49 UTC
I too have seen this effect in my code.
A curses base prompt C function clears the screen on the second call. The 
getch call is where this happens and several other curses commands are 
executed before this happens.
The identical code run under SunOS works fine.
Curses is run in the "filter()" one line mode.
As my code returns (and thus executed between the correct and incorrectly 
executed getch()) are; move(0,0), clrtoeol, endwin, setlinebuf(stdout).

I request that you reopen this bug!

Fedora Core 3

Comment 3 Erik Petrini 2005-09-22 08:20:26 UTC
It seems it is not the getch() call in particular. Any call after an endwin() 
will clear the terminal window.

Example code:

/* gcc main.c -lcurses */

#include <curses.h>

int main(int argc, char* argv[])
  char buffer[1024];
  filter();     /* One line curses only */
  initscr();    /* Initscr sets up curses */

  cbreak();     /* Intercept keyboard input */
  noecho();     /* Don't echo typed characters */
  keypad(stdscr,TRUE); /* Allow special keypad characters */

  /* Curses changes up the buffering of STDOUT */

  printf("Hejsan hoppsan\n");

  refresh(); /* This should not reset the entire screen !!! */


Comment 4 Petr Raszyk 2005-09-23 11:32:21 UTC
I have tried this example. I see this as a bug.

Comment 5 Petr Raszyk 2005-09-30 11:48:29 UTC
Hi Erik,

thanks for your investigation and example.

The bug is in: a) endwin() ->  _nc_mvcur_wrap()
                  We should not call in the function _nc_mvcur_wrap():
                  if filter_mode == TRUE

               b) doupdate()  -> _nc_mvcur_resume()
                  We should not call in the function _nc_mvcur_resume():
                  if filter_mode == TRUE

'filter_mode' is set in the function filter().
I send you a corresponding patch/*.src.rpm today.
It seams, your example works fine. Can you test it (using your software) ?

NOTE:  - Full paths:
         ncurses/base/lib_newterm.c      #filter()
         ncurses/tty/lib_mvcur.c         #_nc_mvcur_wrap(), _nc_mvcur_resume()
       - I could not add a new member into screen-struct (in this case will 
         be the whole screen 'cleared' first time (before any 'newterm' exists) 
         and we do not restore 'original' screen after endwin().
         And that is why we use a global variable: _nc_internal_filter_mode).


Comment 6 Petr Raszyk 2005-09-30 13:35:29 UTC
Created attachment 119465 [details]
rpm package

There is ncurses-5.4-19.src.rpm (including a patch for the issue above).

Comment 11 Petr Raszyk 2005-11-07 12:24:50 UTC
A MAIL from <Erik.Petrini.se>


I'll have a sysmgr download the patch to our trial machine for testing.
I'll get back to you with the results next week.

Thanks for your swift response to this matter.

/ Erik

Comment 12 Petr Raszyk 2005-11-07 12:26:07 UTC
A MAIL from <Erik.Petrini.se>


The patch seemed to fix the bug I was wrestling with.

However, once I got rid of the described problem, I (of course) found
some new ones.

It seems that if I sent a series of quick commands into my curses code,
it is possible for the screen output to get out of synch with my
internal representation.

E.g. i type a full row of characters onto the screen and then press
As the cursor moves, it will actually skip a couple of the characters
and not delete them (they are deleted from my internal buffer though). 
This may of course be coupled to how I use curses, which may not be
optimal since this is the first application I have used it in.

If I run a debugger (ddd) the effect is gone, and I have never seen it
in the sun implementation.

Is there some parallel thread that executes that I need to wait for
before processing the next character in the buffer, and if so, how can I
check that it is done?
If not, what is the cause of this behaviour?

My operations are basically
addstr(My Buffer)
move(0,cursor position)

Then I read a new input and process my buffer and change the cursor
position value)

I guess the bugzilla 2966 is resolved (unless this new behavior is due
to the fix), but this might be the next bug to tackle.

/ Erik Petrini

Comment 13 Petr Raszyk 2005-11-07 12:27:27 UTC
Hi Erik,

there is not thread in ncurses. But see the ncurses-function
typeahead (int);


The  curses  library does line-breakout optimization by looking for
typeahead periodically while updating the screen.  If input  is  found,
and  it  is  coming  from  a tty, the current update is postponed until
refresh or doupdate is called again.  This allows  faster  response  to
commands  typed in advance.  Normally, the input FILE pointer passed to
newterm, or stdin in the case that initscr was used, will be used to do
this typeahead checking.  The typeahead routine specifies that the file
descriptor fd is to be used to check for typeahead instead.  If  fd  is
-1, then no typeahead checking is done.

Can you prepare a working example demonstrating your issue ?
Can you send me this source ?
Can you describe how to reproduce this issue using your example ?
(for instance 'hold pressing KEY_BACKSPACE for 2 seconds' ?).

Together, we will find a solution.


Comment 14 Petr Raszyk 2005-11-07 12:28:47 UTC
A MAIL from <Erik.Petrini.se>

Here is an example of part of our code.

The lineRewrite I use a lot, so if there's anything about it that is bad
I'd love to know.

Problem description:
* Garbled row when run on linux
* Last letter not printed until after getch() return on niether Linux
gcc, SUN gcc or SUN SPARC. (Which makes me wonder if my code really is
that good an implementation.)

I did not find the "key depressed" problem with timing that I was
expecting with this code, but the other problems are bad enough.

Hope this brings some insight.

/ Erik

Comment 15 Petr Raszyk 2005-11-07 12:37:06 UTC
Hi Erik,

there is a small type-mistake in your source.
See at your FOR-CYCLE:

   for  (i=0; i < limit; i++)
        strncpy (cmd, mystr, i);
        cmd [i] = '\0';                     
        lineRewrite (4, 4, cmd);   
        sleep (sleep_time)                          

The first time is i=0. In this case you call:  strncpy (cmd, mystr, 0);
The third parameter on strncpy() is 0. In this case, strncpy() do not
Then, cmd[0]='\0'; creates an empty string.
Then, you print (addstr()) an empty string. It does not do anything.
Your for-cycle runs 20x. But the first time it prints 'nothing'.
Therefore, you can not see the letter 't' (== mystr [19]).
You 'strncpy' at most 19 characters mystr[0] - mystr[18]

The right source is:

   for  (i=1; i <= limit; i++)
        strncpy (cmd, mystr, i) 
        cmd [i] = '\0'                              
        lineRewrite (4, 4, cmd)                     
        sleep (sleep_time)                          
     getch ()      

After this, your example works fine.

Tested in:
 using ncurses 5.4 Rel.19  (static linked).





There is no text after program-termination (before last getch()).

Petr Raszyk

Comment 16 Petr Raszyk 2005-11-07 12:41:27 UTC
A MAIL from <Erik.Petrini.se>

Hi Petr,

I actually wanted to make a null print to test the code, but I messed up
between the loops. After I let the first loop go all the way to i=limit,
it behaves as I intended in SUN gcc/SPARCworks.

Unfortunately, I still have problems. I have attached my updated program
and text+image of how it behaves. (+ a.out if that will help)

We run xterm, FEDORA 3 and your updated ncurses 5.4.19. When run slowly
(delay > 0), the first 4 letters are outputted as they should, and then
all hell breaks loos on the row.

Do you know of any other curses issues dealt with between FEDORA 3 and

/ Erik Petrini

Comment 17 Petr Raszyk 2005-11-07 12:44:01 UTC
Hi Erik,
I have tried your example in FEDORA CORE 3. It works fine
(sleep (1), sleep (0), ...).

Where is your terminal-emulator running ? SUN OS ? What is your
TERM setting ? (echo $TERM).

export TERM=xterm ?
export TERM=winterm ?
export TERM=dterm ?

There can be a possible problem. 'Our' test-application reads
terminfo-database description on Linux-side. Your terminal-emulator
'does not understand' all capabilities (probably).
Please, try our test-application in Linux-console (Ctrl Alt F1) or 
xterm (but running in FEDORA CORE 3).


Comment 18 Petr Raszyk 2005-11-07 12:46:23 UTC
A MAIL from <Erik.Petrini.se>

Hi Petr,

TERM=xterm on both my terminal machine (Sun) and our linux machine.
I log in via ssh.
I do not have physical access to the target machine (linux).
I also just tested to log into an SGI to compile and run, and that
worked fine.

Let me know what more info you need! I'll get in touch with our adm:s if
i need something more exotic.

/ Erik

Comment 19 Petr Raszyk 2005-11-07 12:48:47 UTC
Hi Erik,
can you try some examples for me ? I will send you two *.tar
files. Place these files in FEDORA CORE 3, please.
1) I will send you my curses-test-demo. It was running in
   Red Hat 6, Red Hat 7, Red Hat 9, SuSE 9.*, Knopix, HP-UNIX, ...
   This is a tarball 'saab2_test.tar'. Please, try:
   a) log in FEDORA CORE 3 (via ssh).
   b) type at command prompt: tar xvf saab2_test.tar
   c) type at command prompt: cd saab2_test
   d) type at command prompt: make -f saab2_test.mak clean
   e) type at command prompt: make -f saab2_test.mak
   f) type at command prompt: ./saab2_test
   g) type at command prompt: the keys arrow-down, arrow-left, 
   h) try to resize (using the mouse) the window (terminal-emulator) .

   Does it work ?

2) I will send you your demo too, but with my-simple-compiler flags.
   We should try following: we will open a Linux-xterm-terminal-emulator
   and display his output to your Sun-machine. In this case will be
   xterm physical running on Linux-side.
   Please try:
   a) open a window (terminal emulator) on your Sun-machine.
   b) type at command prompt: xhost +
   c) log in FEDORA CORE 3 via 'telnet' (or via   'ssh -X').
      'telnet' is for our tests better.
   d) type at command prompt: export DISPLAY='your IP-address'
      (but only if you are logged via 'telnet'. Do not set
       this shell-environment-variable, if you are
       logged via 'ssh -X' !!!).
   e) type at command prompt: nohup xterm -fn 8x16 &
      (it launchs Linux-xterm and displays his output to Sun-machine
   f) type at command prompt: tar xvf saab_ori_test.tar
   c) type at command prompt: cd saab_ori_test
   d) type at command prompt: make -f saab_ori_test.mak clean
   e) type at command prompt: make -f saab_ori_test.mak
   f) type at command prompt: ./saab_ori_test

   Does it work ?
   Let me know what is wrong.

Comment 20 Petr Raszyk 2005-11-07 12:51:00 UTC
Hi Erik,

there is an example how to set DISPLAY:
The IP-address of my machine is

In this case I must set:

export DISPLAY=

I have forgot the ':0.0' suffix.
You must set:
export DISPLAY='your IP-address':0.0
I wrote export DISPLAY='your IP-address'.
This is wrong.


Comment 21 Petr Raszyk 2005-11-07 12:51:37 UTC
Hi Erik,
and there are *.tar files:


Comment 22 Petr Raszyk 2005-11-07 12:54:23 UTC
A MAIL from <Erik.Petrini.se>


I've finally gotten around to doing the tests for you. The results
indicate that the problem lies in the terminals somewhere.

A) The saab2_test failed when run as specified. Please see the attached
.tar file for screenshots. There is a lot of garbling going on.

B) The saab_ori test was sucessful! And with the terminal you provided i
sucessfully ran my original test code as well as our main application
without observing any problems. "saab2_test" also worked and had color +
no garbling!

==> It works, but only for the nohup xterm 8x17 &   (Started from ssh -X
login to an xhost + :ed machine (we do not run telnet servers))

What differs this term from the ones we usually use?

Are there any fixes to the linux term that will make it compatible with
the sun term?

Or is the error in the sun term? But then why do other OS work well with


/ Erik Petrini

Comment 23 Petr Raszyk 2005-11-07 12:57:16 UTC
Hi Erik,

we need to know, what is your terminal emulator in SUN OS.
Is this 'xterm' (from X.Org Foundation)? I do not think so. This is
probably a Sun Microsystem product. It has probably own name
(winterm ?, dterm ? sunterm ?) and different behaviour than 
'xterm' (X.Org Foundation). It has its own termcap/terminfo
descriptioin. I will call this emulator 'sunterm'.
You have two possiblities. You have (or you install) 'xterm'
from  X.Org Foundation in your SUN OS and you launch xterm
in SUN OS (at the SUN OS command prompt: nohup xterm -fn 8x16 &) and
after this you log in FEDORA CORE 3 (via ssh). 
Type (after log-in) at the FEDORA CORE 3 command prompt: 
export TERM=xterm

Or you install terminfo description for 'sunterm' in 
Try following: 1) Launch any termnal-emulator in SUN OS (launch 
                  your 'sunterm').                  
               2) type at the SUN OS command prompt: echo $TERM
                  Is this a 'sunterm' ?
               3) type at the command prompt: infocmp > my_sun_term.txt
               4) transfer this file to FEDORA CORE 3
               4) Log in FEDORA CORE (as 'root').
               5) type at the FEDORA CORE 3 command prompt: 
                  tic my_sun_term.txt
               6) Log out from FEDORA CORE 3
               7) Log in FEDORA CORE 3
               8) type at the FEDORA CORE 3 command prompt:
                  export TERM=sunterm
               9) Launch your terminal oriented       

Does it work ?

Petr Raszyk

Comment 24 Petr Raszyk 2005-11-07 12:58:44 UTC
A MAIL from <Erik.Petrini.se>

Hello Petr,

Our sysadm tried to compile a term called rxvt for me to try. This solved the
problem of random writing on the row, but resurrected the original problem of
clearing the screen. (Even though it was the same code run on the same remote

He will now recompile the complete xterm from xterm.org, but has told me that he
won't have it done for at least a week.

I didn't get any feedback on the procedure you sent so I'll ask him.

/ Erik Petrini

Comment 25 Petr Raszyk 2005-11-07 13:01:14 UTC
A MAIL from <Erik.Petrini.se>


Patrik and I have now tried the TERM settings:

Here is what he did:
The terminal emulator we use on Solaris is xterm from SUN's X11R6.4.1. I
exported the terminfo entry for xterm on Solaris 8 (infocmp xterm >
sun.tic) and renamed the entry from xterm to sunterm in the resulting

The I imported this file the FC3 machine (tic sun.tic) and Erik tested
it from SUN's xterm with $TERM=sunterm.

That worked for the latter of our problems (wild typing over the

Sadly, I then decided to stress the system further, and ran our prompt
application and resized the terminal window. That made my original
problem of screen clearing reappear...  It doesn't do that when running
on the sun. But on Linux the problem is there even when running an xterm
from the Linux machine. I don't mind ncurses messing up the present row,
but after the resize the problem is persistent.

So the ncurses clearing of screen issue is not completely resolved,
although it seems we can get around the other problem by setting the
TERM entries.

/ Erik

Comment 26 Petr Raszyk 2005-11-07 13:03:23 UTC
Hi Erik,

the problem is complex (ncurses, SUN OS, Linux, xterm,
terminfo, SUN terminal-emulators, ...).
You should open a new official bug (for instance
ncurses-bug), please.
Then I can ask other RedHat developers. I do not
get a answer if the bug is not official.


Comment 27 Petr Raszyk 2005-11-07 13:13:28 UTC
A MAIL from <Erik.Petrini.se>


I'd just like to ask you if you got my previous mail where I announced
that the changed terminfo worked, but that I still have problems with
window resizing.

/ Erik

Comment 28 Petr Raszyk 2005-11-07 13:40:19 UTC
A MAIL from <Erik.Petrini.se>


I don't think the SunTerm has anything to do with this new bug (the
resize issue). I'll try to get access to the linux comp, but it may take
a while.

You can't cover it under 2966? Or do you need something with a more
proper title?

Problem is we're running the patch you sent us in response to 2966, so I
can't file it as an "official" bug. I wouldn't know if the bug is
present in the official version since the problems in official (2966)
will mask this bug.

/ Erik

Comment 29 Petr Raszyk 2005-11-07 15:02:30 UTC
Hi Erik,

Linux-ncurses supports terminal-resizing. A classic curses does not
do this.
The reason is: classic curses assumes a physically existing terminal
(hard-ware). For instance VT100 == physically existing terminal ==
physically existing hard-ware.
The classic curses is not able to do difference between an 
emulator and physically-existing-terminal.
There is no ESC-sequence to distinguish between an emulator and
a physically terminal.
In other words: a terminal-emulator does not emit an ESC-sequence
(an 'info'): I am terminal-emulator / I am physically existing hard-ware.
That is why a classic curses does not expect a possibility to
'resize a hard-ware'. This is not possible. You can not resize 
(using mouse) a hard-ware.

In contrast, ncurses assumes a graphic-terminal-emulator.
For this case a 'new' signal is defined (SIGWINCH).
This signal must be defined in OS (where your terminal-oriented-application is
and your terminal-emulator must be able to send
an info to generate a SIGWINCH signal on remote site.

terminal-emulator -> pty-device -> SIGWINCH -> application.

You see, there are at least three conditions:
a) curses/ncurses ?
b) SIGWINCH: yes/no ?
c) terminal-emulator: resizing implemented ?
d) a terminal-oriented-application can 'catch' SIGWINCH and
   such application can do 'own things'.

Now, it is time to ask you, what is your 'real' issue ?
a) one line curses/ncurses ? filter()-function ?
b) SUN OS ?
c) terminal-emulators running in SUN OS ?
d) resizing a terminal-oriented application ?
e) a basic curses/ncurses knowledge ?
f) a basic terminal-emulators knowledge ?
g) a basic programming course ?
h) a basic Linux/UNIX knowledge ?
i) a BASIC ?

I will help you with your 'issue', but it is not possible.
Your 'issues'==questions (exlude #2966 (you are not the first 
are (at least) dubious and never ending.

In other words: I will close this bug -> FIXED IN CURRENT RELEASE.

Comment 30 Petr Raszyk 2005-11-07 19:51:50 UTC
Petr Raszyk, 


Comment 31 Petr Raszyk 2005-11-09 09:34:00 UTC
A MAIL from <Erik.Petrini.se>


Did you make the last entry in the Bugzilla 2966, or has your account
been hacked?

I find the entry somewhat unprofessional.

/ Erik Petrini

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