I suggest any of these 3 books (1 is enough to start with; you can get the others later):
W Richard Stevens, Stephen A Rago
[Advanced Programming in the Unix Environment, 3rd Edn](http://smile.amazon.com/Advanced-Programming-UNIX-Environment-Edition/dp/0321637739) —
Marc J Rochkind
[Advanced Unix Programming, 2nd Edn](http://smile.amazon.com/Advanced-UNIX-Programming-2nd-Edition/dp/0131411543) —
Michael Kerrisk
[The Linux Programming Interface: A Linux and Unix System Programming Handbook](http://smile.amazon.com/The-Linux-Programming-Interface-Handbook/dp/1593272200).
The nohup command is the poor man's way of running a process as a daemon. As Bruno Ranschaert noted, when you run a command in an interactive shell, it has a controlling terminal and will receive a SIGHUP (hangup) signal when the controlling process (typically your login shell) exits. The nohup command arranges for input to come from /dev/null, and for both output and errors to go to nohup.out, and for the program to ignore interrupts, quit signals, and hangups. It actually still has the same controlling terminal - it just ignores the terminals controls. Note that if you want the process to run in the background, you have to tell the shell to run it in the background - at least on Solaris (that is, you type 'nohup sleep 20 &'; without the ampersand, the process runs synchronously in the foreground).
Typically, a process run via nohup is something that takes time, but which does not hang around waiting for interaction from elsewhere.
Typically (which means if you try hard, you can find exceptions to these rules), a daemon process is something which lurks in the background, disconnected from any terminal, but waiting to respond to some input of some sort. Network daemons wait for connection requests or UDP messages to arrive over the network, do the appropriate work and send a response back again. Think of a web server, for example, or a DBMS.
When a process fully daemonizes itself, it goes through some of the steps that the nohup code goes through; it rearranges its I/O so it is not connected to any terminal, detaches itself from the process group, ignores appropriate signals (which might mean it doesn't ignore any signals, since there is no terminal to send it any of the signals generated via a terminal). Typically, it forks once, and the parent exits successfully. The child process usually forks a second time, after fixing its process group and session ID and so on; the child then exits too. The grandchild process is now autonomous and won't show up in the ps output for the the terminal where it was launched.
I have a program daemonize which will daemonize a program that doesn't know how to daemonize itself (properly). It was written to work around the defects in a program which was supposed to daemonize itself but didn't do the job properly. Contact me if you want it - see my profile.
Have you looked in <curses.h> to see what the getch() function does?
Hint: OSX and Linux are not the same as Windows.
Specifically, as a macro in <curses.h>, we find:
#define getch() wgetch(stdscr)
Now, there appears, on your system, to be an actual function getch() in the curses library, but it expects stdscr to be set up, and that is done by the curses initialization functions (initscr() and relatives), and that is signally not done by your code. So, your code is invoking undefined behaviour by calling curses routines before the correct initialization is done, leading to the crash.
(Good hint from dmckee - it helped get the link line out of acidzombie24, which was important.)
To get to a point where a single key-stroke can be read and the program terminated cleanly, you have to do a good deal of work on Unix (OSX, Linux). You would have to trap the initial state of the terminal, arrange for an atexit() function - or some similar mechanism - to restore the state of the terminal, change the terminal from cooked mode into raw mode, then invoke a function to read a character (possibly just read(0, &c, 1)), and do your exit. There might be other ways to do it - but it certainly will involve some setup and teardown operations.
It may be simplest to use the expect program; it does most of the necessary work for you.
The necessary work is fiddly. It involves using pseudo-ttys, which are devices that look to programs like terminals. If you're going to roll your own, then the POSIX system calls you need to know about are:
posix_openpt()
ptsname()
granpt()
unlockpt()
The posix_openpt() interface is relatively new (Issue 6, compared with Issue 4, Version 2 for the other functions listed). If your system doesn't have posix_openpt(), you need to get yourself one of the Unix books (Stevens or Rochkind, probably) to find out how else to do open the master side of a pty, or read your system manuals rather carefully. However, the rationale for posix_openpt() at the link above may also help — it also has guidelines for using the other functions. Linux has posix_openpt(); so does Mac OS X and by inference the BSD systems generally.
The
nohupcommand is the poor man's way of running a process as a daemon. As Bruno Ranschaert noted, when you run a command in an interactive shell, it has a controlling terminal and will receive a SIGHUP (hangup) signal when the controlling process (typically your login shell) exits. Thenohupcommand arranges for input to come from/dev/null, and for both output and errors to go tonohup.out, and for the program to ignore interrupts, quit signals, and hangups. It actually still has the same controlling terminal - it just ignores the terminals controls. Note that if you want the process to run in the background, you have to tell the shell to run it in the background - at least on Solaris (that is, you type 'nohup sleep 20 &'; without the ampersand, the process runs synchronously in the foreground).Typically, a process run via
nohupis something that takes time, but which does not hang around waiting for interaction from elsewhere.Typically (which means if you try hard, you can find exceptions to these rules), a daemon process is something which lurks in the background, disconnected from any terminal, but waiting to respond to some input of some sort. Network daemons wait for connection requests or UDP messages to arrive over the network, do the appropriate work and send a response back again. Think of a web server, for example, or a DBMS.
When a process fully daemonizes itself, it goes through some of the steps that the
nohupcode goes through; it rearranges its I/O so it is not connected to any terminal, detaches itself from the process group, ignores appropriate signals (which might mean it doesn't ignore any signals, since there is no terminal to send it any of the signals generated via a terminal). Typically, it forks once, and the parent exits successfully. The child process usually forks a second time, after fixing its process group and session ID and so on; the child then exits too. The grandchild process is now autonomous and won't show up in thepsoutput for the the terminal where it was launched.You can look at Advanced Programming in the Unix Environment, 3rd Edn by W Richard Stevens and Stephen A Rago, or at Advanced Unix Programming, 2nd Edn by Marc J Rochkind for discussions of daemonization.
I have a program
daemonizewhich will daemonize a program that doesn't know how to daemonize itself (properly). It was written to work around the defects in a program which was supposed to daemonize itself but didn't do the job properly. Contact me if you want it - see my profile.Have you looked in
<curses.h>to see what thegetch()function does?Hint: OSX and Linux are not the same as Windows.
Specifically, as a macro in
<curses.h>, we find:Now, there appears, on your system, to be an actual function
getch()in the curses library, but it expectsstdscrto be set up, and that is done by the curses initialization functions (initscr()and relatives), and that is signally not done by your code. So, your code is invoking undefined behaviour by calling curses routines before the correct initialization is done, leading to the crash.(Good hint from dmckee - it helped get the link line out of acidzombie24, which was important.)
To get to a point where a single key-stroke can be read and the program terminated cleanly, you have to do a good deal of work on Unix (OSX, Linux). You would have to trap the initial state of the terminal, arrange for an
atexit()function - or some similar mechanism - to restore the state of the terminal, change the terminal from cooked mode into raw mode, then invoke a function to read a character (possibly justread(0, &c, 1)), and do your exit. There might be other ways to do it - but it certainly will involve some setup and teardown operations.One book that might help is Advanced Unix Programming, 2nd Edn by Mark Rochkind; it covers terminal handling at the level needed. Alternatively, you can use
<curses.h>properly - that will be simpler than a roll-your-own solution, and probably more reliable.It may be simplest to use the
expectprogram; it does most of the necessary work for you.The necessary work is fiddly. It involves using pseudo-ttys, which are devices that look to programs like terminals. If you're going to roll your own, then the POSIX system calls you need to know about are:
posix_openpt()ptsname()granpt()unlockpt()The
posix_openpt()interface is relatively new (Issue 6, compared with Issue 4, Version 2 for the other functions listed). If your system doesn't haveposix_openpt(), you need to get yourself one of the Unix books (Stevens or Rochkind, probably) to find out how else to do open the master side of a pty, or read your system manuals rather carefully. However, the rationale forposix_openpt()at the link above may also help — it also has guidelines for using the other functions. Linux hasposix_openpt(); so does Mac OS X and by inference the BSD systems generally.Books:
W Richard Stevens, Stephen A Rago Advanced Programming in the Unix Environment, 3rd Edn
Marc J Rochkind Advanced Unix Programming, 2nd Edn