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: ... doupdate(); /* Get input from the user and process it */ while(NotDone) { i=getch(); ... Well, when 'getch' is called, the screen goes black. It happens in an xterm and on the text console. Redhat 6.0 safedelete-1.3-4 ncurses-4.2-18 ncurses-devel-4.2-18
this seems to be a bug in undelete's code, and not in ncurses.
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 libncurses.so.5.4
Addition: 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 */ strcpy(buffer,"HelloWorld"); addstr(buffer); refresh(); getch(); move(0,0); endwin(); /* Curses changes up the buffering of STDOUT */ setlinebuf(stdout); printf("Hejsan hoppsan\n"); fflush(0); refresh(); /* This should not reset the entire screen !!! */ getch(); endwin(); }
I have tried this example. I see this as a bug.
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(): mvcur(...); putp(exit_ca_mode); if filter_mode == TRUE b) doupdate() -> _nc_mvcur_resume() We should not call in the function _nc_mvcur_resume(): putp(enter_ca_mode); 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). Regards, Petr
Created attachment 119465 [details] rpm package There is ncurses-5.4-19.src.rpm (including a patch for the issue above).
A MAIL from <Erik.Petrini.se> Hello, 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
A MAIL from <Erik.Petrini.se> Hello, 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 backspace. 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 move(0,startofline) clrtoeol() addstr(My Buffer) move(0,cursor position) refresh() 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. Sincerely / Erik Petrini
Hi Erik, there is not thread in ncurses. But see the ncurses-function typeahead (int); 'man'-pages: 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. Regards, Petr
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
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); printa("printing=>%s<n",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 anything. 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: FEDOR CORE 4 xterm using ncurses 5.4 Rel.19 (static linked). Result: ------------------------------------------- a ab abc abcd abcde abcdef abcdefg abcdefgh abcdefghi abcdefghij abcdefghijk abcdefghijkl abcdefghijklm abcdefghijklmn abcdefghijklmno abcdefghijklmnop abcdefghijklmnopq abcdefghijklmnopqr abcdefghijklmnopqrs abcdefghijklmnopqrst <Enter> abcdefghijklmnopqrst abcdefghijklmnopqrs abcdefghijklmnopqr abcdefghijklmnopq abcdefghijklmnop abcdefghijklmno abcdefghijklmn abcdefghijklm abcdefghijkl abcdefghijk abcdefghij abcdefghi abcdefgh abcdefg abcdef abcde abcd abc ab a There is no text after program-termination (before last getch()). Regards, Petr Raszyk
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 4? Sincerely / Erik Petrini
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). Regards, Petr
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. Sincerely / Erik
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, arrow-up 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 only). 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. Regards, Petr
Hi Erik, there is an example how to set DISPLAY: The IP-address of my machine is 192.168.1.14 In this case I must set: export DISPLAY=192.168.1.14:0.0 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. Regards, Petr
Hi Erik, and there are *.tar files: Regards, Petr
A MAIL from <Erik.Petrini.se> Hello, 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 sun? Sincerely / Erik Petrini
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 FEDORA CORE 3. 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 applicatioin Does it work ? Regards, Petr Raszyk
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 machine.) 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. Sincerely / Erik Petrini
A MAIL from <Erik.Petrini.se> Hi, Patrik and I have now tried the TERM settings: Here is what he did: Quote: 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 file. The I imported this file the FC3 machine (tic sun.tic) and Erik tested it from SUN's xterm with $TERM=sunterm. :UnQuote That worked for the latter of our problems (wild typing over the screen). 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. Sincerely / Erik
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. Regards, Petr
A MAIL from <Erik.Petrini.se> Hello, 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
A MAIL from <Erik.Petrini.se> Hi, 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. Sincerely / Erik
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 running) 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 reporter)) are (at least) dubious and never ending. In other words: I will close this bug -> FIXED IN CURRENT RELEASE.
I, Petr Raszyk, decided: !!! NO ANSWER TO YOUR DUBIOUS ISSUE ABOVE !!!
A MAIL from <Erik.Petrini.se> Hello, Did you make the last entry in the Bugzilla 2966, or has your account been hacked? I find the entry somewhat unprofessional. Sincerely / Erik Petrini