2

I am trying to run an ncurses GUI application on an ARM board. I am running it using the serial console ttyAMA0 port. But when I run the ncurses program, the other processes running in the background will print debug messages i.e qDebug, qWarning into STDOUT i.e on the GUI layout and hence results in noise. I think the problem is because all the processes are using the same console device.

So is there is a command line or programmatic solution for this problem so that I could not see the other process' STDOUT on my ncurses GUI ?

I tried GNU screen It is not really helping. Even in screen session I am seeing the output of those processes polluting the screen

P.S: I have tried gdb solution and it works fine. But I want alternative solution for this

3

I don't think what you want is possible. See this superuser thread titled: How do I detach a process from Terminal, entirely?.

I think you have essentially 3 options.

Option #1

Run the scripts that are polluting you terminal such that they're run like so:

nohup somescript &> /dev/null &

Which should run their STDOUT & STDIN to /dev/null, background them, and disconnect them from your terminal's signals if you should close it.

Option #2

Use something like screen. Thanks to @StephaneChazelas in the comments it does appear that there are screen packages available for Debian on your architecture.

Option #3

If you don't care if you temporarily pause the processes that are polluting your terminal's STDOUT you can use this setting: stty tostop. This has the effect of stopping these processes from sending their STDOUT to your terminal. When you're done you can re-enable it with the command stty -nostop. I found this in the Unix Power Tools 3rd edition book.

example

Here's my example app that is polluting my terminal's STDOUT:

$ while [ 1 ];do echo hi 2>&1;sleep 5;done &

This echoes out "hi" every 5 seconds like so:

[1] 30913
hi
$ hi
hi
hi
hi

Now when I run stty tostop:

$ stty tostop
$ date
Thu May  9 14:22:44 EDT 2013
$ date
Thu May  9 14:23:52 EDT 2013

The trouble with this approach is that the other process is stopped:

$ jobs
[1]+  Stopped                 while [ 1 ]; do
    echo hi 2>&1; sleep 5;
done

The trouble with this approach is that stty -tostop didn't resume the process, just the setting of my stty stating that STDOUT is allowed again. So I had to resume my process manually:

$ stty -tostop
$ jobs
[1]+  Stopped                 while [ 1 ]; do
    echo hi 2>&1; sleep 5;
done

$ fg
while [ 1 ]; do
    echo hi 2>&1; sleep 5;
done
hi
^Z

[1]+  Stopped                 while [ 1 ]; do
    echo hi 2>&1; sleep 5;
done
$ bg
[1]+ while [ 1 ]; do
    echo hi 2>&1; sleep 5;
done &
$ hi
hi
hi
hi
hi

The above shows my running stty -tostop, then running the command fg to foreground the while ... process that was polluting my STDOUT, then Ctrl+Z, to stop the while ... process, then use the background command, bg.

Additional Ideas

Check out the suggestions tools on these U&L Q&As

There are extensive lists of tools and possible paths for you to try out as alternatives to screen. Perhaps use tmux or reconnect the processes that are polluting your STDOUT to another terminal using reptyr.

  • Option 1: Will not help as I dont have access to those polluting processes Option 2: Have problems cross compiling screen for ARM – GeekFactory May 9 '13 at 4:14
  • There are screen packages for arm in Debian and probably most other distributions supporting arm. – Stéphane Chazelas May 9 '13 at 13:11
  • Sorry my mistake. Even screen command is not helping. I tried this I started a process in bg and then opened screen session. Even then in the new screen session I see the pollution – GeekFactory May 10 '13 at 4:32
  • How did you launch the screen sessions? This can make a difference. – slm May 10 '13 at 5:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.