def_prog_mode(), def_shell_mode(), reset_prog_mode(), reset_shell_mode(), resetty(), savetty(), getsyx(), setsyx(), ripoffline(), curs_set(), napms() - low-level xscurses routines


#include <curses.h>

int def_prog_mode(void); int def_shell_mode(void); int reset_prog_mode(void); int reset_shell_mode(void); int resetty(void); int savetty(void); void getsyx(int y, int x); void setsyx(int y, int x); int ripoffline(int line, int (*init)(WINDOW *, int)); int curs_set(int visibility); int napms(unsigned int ms);


The following routines give low-level access to various curses capabilities. Theses routines typically are used inside library routines.

The def_prog_mode(3) and def_shell_mode(3) routines save the current terminal modes as the program (in curses or shell (not in curses state for use by the reset_prog_mode(3) and reset_shell_mode(3) routines. This is done automatically by initscr(3). There is one such save area for each screen context allocated by newterm(3).

The reset_prog_mode(3) and reset_shell_mode(3) routines restore the terminal to program or shell state. These are done automatically by endwin(3) and, after an endwin(3), by doupdate(3), so they normally are not called.

The resetty(3) and savetty(3) routines save and restore the state of the terminal modes. savetty(3) saves the current state in a buffer and resetty(3) restores the state to what it was at the last call to savetty.

The getsyx(3) routine returns the current coordinates of the virtual screen cursor in y and x. If leaveok(3) is currently TRUE, then -1,-1 is returned. If lines have been removed from the top of the screen, using ripoffline(3), y and x include these lines; therefore, y and x should be used only as arguments for setsyx(3).

The setsyx(3) routine sets the virtual screen cursor to y, If y and x are both -1, then leaveok(3) is set. The two routines getsyx(3) and are designed to be used by a library routine, which manipulates curses windows but does not want to change the current position of the program's cursor. The library routine would call getsyx(3) at the beginning, do its manipulation of its own windows, do a wnoutrefresh(3) on its windows, call setsyx(3), and then call doupdate(3).

The ripoffline(3) routine provides access to the same facility that slk_init(3) (see curs_slk) uses to reduce the size of the screen. ripoffline(3) must be called before initscr(3) or newterm(3) is called. If line is positive, a line is removed from the top of stdscr if line is negative, a line is removed from the bottom. When this is done inside initscr(3), the routine init() (supplied by the user) is called with two arguments: a window pointer to the one-line window that has been allocated and an integer with the number of columns in the window. Inside this initialization routine, the integer variables LINES and COLS (defined in <curses.h>) are not guaranteed to be accurate and wrefresh(3) or doupdate(3) must not be called. It is allowable to call wnoutrefresh(3) during the initialization routine.

ripoffline(3) can be called up to five times before calling initscr(3) or newterm(3).

The curs_set(3) routine sets the cursor state is set to invisible, normal, or very visible for visibility equal to 0, 1, or 2 respectively. If the terminal supports the visibility requested, the previous cursor state is returned; otherwise, ERR is returned.

The napms(3) routine is used to sleep for ms milliseconds.


Except for curs_set(3), these routines always return OK. curs_set(3) returns the previous cursor state, or ERR if the requested visibility is not supported.


getsyx(3) is a macro, so & is not necessary before the variables y and x.

The SVr4 man pages warn that the return value of curs_set(3) "is currently incorrect". This implementation gets it right, but it may be unwise to count on the correctness of the return value anywhere else.


The functions setsyx(3) and getsyx(3) are not described in the XSI Curses standard, Issue 4. All other functions are as described in XSI Curses.

The SVr4 documentation describes setsyx(3) and getsyx(3) as having return type int. This is misleading, as they are macros with no documented semantics for the return value.