Ncurses to External Shell and Back Messing with Keys

C - going from ncurses ui to external program and back

I've never had to restart curses entirely.

what if you do something like

def_prog_mode() then
endwin()

execute system call

and refresh() should restore it

NCurses: reading input from other terminal misses keys

Using G.M.'s hint, I was able to reliably get all input.
Run

tail -f /dev/null

in the curses-terminal before attaching the ncurses app.
Should you be tempted (like me) though to send this command from within your app after fopen, you may end up frustrated.

Cross compiled ncurses for UTF-8 displays incorrectly

Ncurses relies on the standard C library which requires a compiled in path to the directories with the internationalized files in them, or else NCURSES will automatically default back to the POSIX locale (AKA "C" locale) and won't do UTF-8.

Cross compiling on a build system where the locales are stored in a different location than the host can cause the autoconfig script to misidentify the directory and then the embedded system will not be able to do UTF-8 even if the locale variables are set correctly ... and worse, it's possible for no error messages to be generated by the failure.

But: If the path is wrong, then you won't be able to see any locales except POSIX & C when running:

locale -a

Setting up a dummy directory on the build system with the internationalized files, and then recompiling the standard C library is one way to solve the problem; but it may require root priveleges.

Alternately, there is an environment variable "I18NPATH" that can be set when using the gnu standard C library (glibc); it is supposed to override the compiled in path. If the install prefix on the embedded system was "/mnt/sd", then from bash shell -- just do:

export I18NPATH="/mnt/sd/share/i18n"

In either event, once the corrected path is available/installed -- the system should operate normally. If not, check to make sure the locale has actually been generated for the combination of country charmap and UTF-8, which is desired (using "locale -a" to list them all).

If it doesn't exist, it can be created very simply using the "localedef" utility. eg: To create a USA english locale with UTF-8 support, just do:

localedef -i en_US -c -f UTF-8 en_US.UTF-8

then, be sure the locale varaibles are set and exported:

export LOCALE=en_US.UTF-8
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8

And then running locale with no arguments should show all variables as being en_US.UTF-8 ... and everything will work fine from then on.

How to effectively debug a multi-threaded curses client-server application with gdb?

You can separate gdb and program's output using tty gdb command. Here is detailed instruction how to do it from Peter's gdb Tutorial:

Go to the first xterm and find its device file using either tty or who am i. This will be the xterm with GDB's I/O.:

   $ tty
   /dev/pts/1
   $ who am i
   p        pts/1        May 26 12:44 (:0.0)

Go to the second xterm and find its device file. This will be the xterm with our program's I/O:

   $ tty
   /dev/pts/4

Go back to the first xterm and start a debugging session. Set a breakpoint at Print_A_Character().

   $ gdb debugging_ncurses
   (gdb) break Print_A_Character 
   Breakpoint 1 at 0x80486fd: file debugging_ncurses.c, line 26.
   (gdb) 

GDB's tty command instructs GDB to redirect the program's I/O to another terminal. The argument to tty is the device file of the terminal you wish the program I/O to go. In this case, I want the program's I/O to go to the second xterm, pts/4. If you're following along, use whatever device file you obtained in step 2:

   (gdb) tty /dev/pts/4
   (gdb) 

Lastly, go to the second xterm (that contains the program's I/O) and tell the shell to sleep for a long time. This is so that anything we type in that window will be sure to go to our program rather than the shell. The amount of time is arbitrary, but pick a time that's longer than you suspect the debugging session will last. This tells the shell to "do nothing" for 100000 seconds:

   $ tty
   /dev/pts/4
   $ sleep 100000

Go back to the first xterm which is running GDB and debug to your heart's content. When you're done, you can go back to the program output window and slap it with a control-c to break out of the sleep.

---

Related Topics