Curses program

Active 9 years, 2 months ago. Viewed 2k times. Keith Nicholas It sounds like you want to run your test program inside of gdb. That way, when you get a core dump, you can 1 get a traceback, and 2 possibly determine the values of relevant variables at the time of crash. When GDB catches a crash, you can use the bt backtrace command to see the call chain.

The use the up command to go to your function. Then you can examine variables to see what might be wrong.

Please read the GDB documentation. Add a comment. Active Oldest Votes. Keith Nicholas Keith Nicholas Sign up or log in Sign up using Google. The curses package comes with the Python standard library. In Linux and Mac, the curses dependencies should already be installed so there is no extra steps needed. On Windows, you need to install one special Python package, windows-curses available on PyPI to add support.

You can verify everything works by running a Python interpreter and attempting to import curses. If you do not get any errors, you are in good shape. There are a few important concepts to understand before digging in to the advanced concepts.

Some primary things you will need to understand are:. These primary topics will be covered first before we look in to some more common tasks like modifying terminal properties to turn off the cursor, listening for key presses, centering text, and more. Now that we are confident the curses import worked, we can try to initialize it.

When you initialize curses, it creates a new window and clears the screen, displaying your new window. This example will show how to initialize curses and obtain a window to work with. We will call the main window screen. After running this example, you might be surprised by the behavior. It will display a blank screen for one second, and then you will see all of your print statements at the end when you return to the terminal.

The print statements continue going to standard output and will remain there, even though it is not visible. If print statements don't go to the screen, then how do you get text on to this fancy new screen we initialized? Now that we know how to initialize a blank screen and clean up at the end, let's try adding text to the screen.

This example shows how to initialize the screen like before, but taking it further and adding a string to the screen. Note that you need to refresh the screen after making changes.

With this knowledge, you can draw text anywhere you want, all over the screen! You can do all kinds of stuff with just this knowledge alone. You may be wondering how you know your limits, like what is the maximum row and maximum column? If you want to fill up the screen or draw a border, what rows and columns should you use? We'll cover that in a later section. You could go through cell by cell and fill it with a black background space character to reset the terminal, but there is a convenient function to clear the screen, with the clear function of a window.

Curses provides two important concepts: windows and pads. So far we have been working with one window, the main screen. You can create multiple windows of different sizes and place them around the screen.

You can do all the same things we showed with the "screen" window like addstr and addch. To pick it off the queue, use the function getmouse you must do this before the next wgetch , otherwise another mouse event might come in and make the first one inaccessible. Each call to getmouse fills a structure the address of which you will pass it with mouse event data.

The event data includes zero-origin, screen-relative character-cell coordinates of the mouse pointer. It also includes an event mask. Bits in this mask will be set, corresponding to the event type being reported. The mouse structure contains two additional fields which may be significant in the future as ncurses interfaces to new kinds of pointing device. In addition to x and y coordinates, there is a slot for a z coordinate; this might be useful with touch-screens that can return a pressure or duration parameter.

There is also a device ID field, which could be used to distinguish between multiple pointing devices. The class of visible events may be changed at any time via mousemask.

Events that can be reported include presses, releases, single-, double- and triple-clicks you can set the maximum button-down time for clicks. If you do not make clicks visible, they will be reported as press-release pairs. In some environments, the event mask may include bits reporting the state of shift, alt, and ctrl keys on the keyboard during the event.

A function to check whether a mouse event fell within a given window is also supplied. You can use this to see whether a given window should consider a mouse event relevant to it. Because mouse event reporting will not be available in all environments, it would be unwise to build ncurses applications that require the use of a mouse. Rather, you should use the mouse as a shortcut for point-and-shoot commands your application would normally accept from the keyboard.

Two of the test games in the ncurses distribution bs and knight contain code that illustrates how this can be done. In order to clean up after the ncurses routines, the routine endwin is provided. It restores tty modes to what they were when initscr was first called, and moves the cursor down to the lower-left corner. Thus, anytime after the call to initscr, endwin should be called before exiting.

We describe the detailed behavior of some important curses functions here, as a supplement to the manual page descriptions. The errret pointer can also be given as NULL, meaning no error code is wanted. If errret is defaulted, and something goes wrong, setupterm will print an appropriate error message and exit, rather than returning. Thus, a simple program can call setupterm 0, 1, 0 and not worry about initialization errors.

Setupterm also stores the names section of the terminal description in the global character array ttytype[]. Subsequent calls to setupterm will overwrite this array, so you will have to save it yourself if need be. Trace logs can be difficult to interpret due to the sheer volume of data dumped in them. There is a script called tracemunch included with the ncurses distribution that can alleviate this problem somewhat; it compacts long sequences of similar operations into more succinct single-line pseudo-operations.

These pseudo-ops can be distinguished by the fact that they are named in capital letters. The ncurses manual pages are a complete reference for this library. In the remainder of this document, we discuss various useful methods that may not be obvious from the manual page descriptions. If you find yourself thinking you need to use noraw or nocbreak , think again and move carefully.

It is probably better design to use getstr or one of its relatives to simulate cooked mode. The noraw and nocbreak functions try to restore cooked mode, but they may end up clobbering some control bits set before you started your application.

Also, they have always been poorly documented, and are likely to hurt your application's usability with other curses libraries. Bear in mind that refresh is a synonym for wrefresh stdscr. Do not try to mix use of stdscr with use of windows declared by newwin ; a refresh call will blow them off the screen. The right way to handle this is to use subwin , or not touch stdscr at all and tile your screen with declared windows which you then wnoutrefresh somewhere in your program event loop, with a single doupdate call to trigger actual repainting.

You are much less likely to run into problems if you design your screen layouts to use tiled rather than overlapping windows. Historically, curses support for overlapping windows has been weak, fragile, and poorly documented. The ncurses library is not yet an exception to this rule. There is a panels library included in the ncurses distribution that does a pretty good job of strengthening the overlapping-windows facilities.

Use getmaxyx on the stdscr context instead. Reason: your code may be ported to run in an environment with window resizes, in which case several screens could be open with different sizes. A common reason for this is to support shell-out. This behavior is simple to arrange in ncurses. To leave ncurses mode, call endwin as you would if you were intending to terminate the program.

This will take the screen back to cooked mode; you can do your shell-out. When you want to return to ncurses mode, simply call refresh or doupdate. This will repaint the screen. There is a boolean function, isendwin , which code can use to test whether ncurses screen mode is active. The refresh will pick up the new screen size from the xterm's environment.

That is the standard way, of course it even works with some vendor's curses implementations. Its drawback is that it clears the screen to reinitialize the display, and does not resize subwindows which must be shrunk.

Ncurses provides an extension which works better, the resizeterm function. That function ensures that all windows are limited to the new screen dimensions, and pads stdscr with blanks if the screen is larger.

When ncurses returns that code, it calls resizeterm to update the size of the standard screen's window, repainting that filling with blanks or truncating as needed.

It also resizes other windows, but its effect may be less satisfactory because it cannot know how you want the screen re-painted. The initscr function actually calls a function named newterm to do most of its work. If you are writing a program that opens multiple terminals, use newterm directly. For each call, you will have to specify a terminal type and a pair of file pointers; each call will return a screen reference, and stdscr will be set to the last one allocated.

Sometimes you may want to write programs that test for the presence of various capabilities before deciding whether to go into ncurses mode. An easy way to do this is to call setupterm , then use the functions tigetflag , tigetnum , and tigetstr to do your testing. The right way to test this is to see if the return value of tigetstr "cup" is non-NULL. Alternatively, you can include the term. Use the addchstr family of functions for fast screen-painting of text when you know the text does not contain any control characters.

Try to make attribute changes infrequent on your screens. Do not use the immedok option! The wresize function allows you to resize a window in place. The keyok function allows you to temporarily enable or disable interpretation of any function-key control sequence. Several terminal emulators support this feature, which is based on ISO Ncurses supports up 16 colors, unlike SVr4 curses which defines only 8.

While most terminals which provide color allow only 8 colors, about a quarter including XFree86 xterm support 16 colors. Despite our best efforts, there are some differences between ncurses and the undocumented! These arise from ambiguities or omissions in the documentation of the API. If you define two windows A and B that overlap, and then alternately scribble on and refresh them, the changes made to the overlapping region under historic curses versions were often not documented precisely.

To understand why this is a problem, remember that screen updates are calculated between two representations of the entire display. The documentation says that when you refresh a window, it is first copied to the virtual screen, and then changes are calculated to update the physical screen and applied to the terminal.

But "copied to" is not very specific, and subtle differences in how copying works can produce different behaviors in the case where two overlapping windows are each being refreshed at unpredictable intervals.

What happens to the overlapping region depends on what wnoutrefresh does with its argument -- what portions of the argument window it copies to the virtual screen. Some implementations do "change copy", copying down only locations in the window that have changed or been marked changed with wtouchln and friends. Some implementations do "entire copy", copying all window locations to the virtual screen whether or not they have changed.

The ncurses library itself has not always been consistent on this score. Due to a bug, versions 1. Versions 1. For most commercial curses implementations, it is not documented and not known for sure at least not to the ncurses maintainers whether they do change copy or entire copy.

We know that System V release 3 curses has logic in it that looks like an attempt to do change copy, but the surrounding logic and data representations are sufficiently complex, and our knowledge sufficiently indirect, that it is hard to know whether this is reliable.

The XSI Curses standard barely mentions wnoutrefresh ; the SVr4 documents seem to be describing entire-copy, but it is possible with some effort and straining to read them the other way.

It might therefore be unwise to rely on either behavior in programs that might have to be linked with other curses implementations. Instead, you can do an explicit touchwin before the wnoutrefresh call to guarantee an entire-contents copy anywhere.

The really clean way to handle this is to use the panels library. If you have been using a very old versions of ncurses 1. In older versions, erased areas of a window were filled with a blank modified by the window's current attribute as set by wattrset , wattron , wattroff and friends.

In newer versions, this is not so. Instead, the attribute of erased blanks is normal unless and until it is modified by the functions bkgdset or wbkgdset. Many extended-level features in fact, almost all features not directly concerned with wide characters and internationalization are also supported. Also, ncurses meets the XSI requirement that every macro entry point have a corresponding function which may be linked and will be prototype-checked if the macro definition is disabled with undef.

The ncurses library by itself provides good support for screen displays in which the windows are tiled non-overlapping. In the more general case that windows may overlap, you have to use a series of wnoutrefresh calls followed by a doupdate , and be careful about the order you do the window refreshes in.

It has to be bottom-upwards, otherwise parts of windows that should be obscured will show through. When your interface design is such that windows may dive deeper into the visibility stack or pop to the top at runtime, the resulting book-keeping can be tedious and difficult to get right. Hence the panels library. The version documented here is the panel code distributed with ncurses. Note that they must also link the ncurses library with -lncurses.

Many linkers are two-pass and will accept either order, but it is still good practice to put -lpanel first and -lncurses second. A panel object is a window that is implicitly treated as part of a deck including all other panel objects.

The deck has an implicit bottom-to-top visibility order. The panels library includes an update function analogous to refresh that displays all panels in the deck in the proper order to resolve overlaps. The standard window, stdscr , is considered below all panels. Details on the panels functions are available in the man pages. We will just hit the highlights here. It then becomes the top of the deck. This will not deallocate the associated window; you have to do that yourself. The new window may be of different size; the panel code will re-compute all overlaps.

This operation does not change the panel's position in the deck. The mvwin function on the panel's window is not sufficient because it does not update the panels library's representation of where the windows are.

This operation leaves the panel's depth, contents, and size unchanged. The first pops its argument window to the top of the deck; the second sends it to the bottom. Either operation leaves the panel's screen location, contents, and size unchanged. You should not mix wnoutrefresh or wrefresh operations with panels code; this will work only if the argument window is either in the top panel or unobscured by any other panels. The stsdcr window is a special case.

It is considered below all panels. Note that wgetch automatically calls wrefresh. Therefore, before requesting input from a panel window, you need to be sure that the panel is totally unobscured. There is presently no way to display changes to one obscured panel without repainting all panels. Other panels operations are applicable.

Handed a panel pointer, they return the panel above or below that panel. Handed NULL , they return the bottom-most or top-most panel. Every panel has an associated user pointer, not used by the panel code, to which you can attach application data. A menu is a screen display that assists the user to choose some subset of a given set of items.

The menu library is a curses extension that supports easy programming of menu hierarchies with a uniform but flexible interface. The version documented here is the menu code distributed with ncurses. Many linkers are two-pass and will accept either order, but it is still good practice to put -lmenu first and -lncurses second. The menus created by this library consist of collections of items including a name string part and a description string part.

To make menus, you create groups of these items and connect them with menu frame objects. The menu can then by posted , that is written to an associated window. Actually, each menu has two associated windows; a containing window in which the programmer can scribble titles or borders, and a subwindow in which the menu items proper are displayed. If this subwindow is too small to display all the items, it will be a scrollable viewport on the collection of items.

A menu may also be unposted that is, undisplayed , and finally freed to make the storage associated with it and its items available for re-use. Both types always have a current item. From a single-valued menu you can read the selected value simply by looking at the current item. This is the only option so far defined for menus, but it is good practice to code as though other option bits might be on.

The menu library calculates a minimum display size for your window, based on the following variables:. The actual menu page may be smaller than the format size. The alternative is column-major display, which tries to put the first several items in the first column. As mentioned above, a menu format not large enough to allow all items to fit on-screen will result in a menu display that is vertically scrollable.

You can scroll it with requests to the menu driver, which will be described in the section on menu input handling. The mark string length also influences the menu page size. There are other menu display attributes including a select attribute, an attribute for selectable items, an attribute for unselectable items, and a pad character used to separate item name text from description text.

Each menu has, as mentioned previously, a pair of associated windows. Both these windows are painted when the menu is posted and erased when the menu is unposted.