in reply to Keep a "system" process running if script is prematurely exited?

I believe the child needs to disconnect STDIN, STDOUT and STDERR from the terminal.

use IPC::Open3 qw( open3 ); open(local *TO_CHLD, '<', '/dev/null') or die; open(local *FR_CHLD, '>', '/dev/null') or die; open3('>&TO_CHLD', '<&FR_CHLD', '<&FR_CHLD', 'kedit');

It might also need to call POSIX's setsid. I'm not sure what it does ( but I think it's what later-mentioned disown does ).

Update: It's the other way around. setsid is required, but replacing STDIN, STDOUT and STDERR is probably not.

Replies are listed 'Best First'.
Re^2: Keep a "system" process running if script is prematurely exited?
by cdarke (Prior) on Jun 17, 2010 at 08:32 UTC
    I'm not sure what it does

    setsid(2) creates a new session and connection to the controlling terminal is lost. The calling process becomes the new session and process group leader. This is commonly used to disconnect from a terminal when writing a daemon.

    I doubt it is relevant here. The editor being launched is an X-Windows application which does not use STDIN/OUT/SHAKEITALLABOUT. Is it Friday yet?
      Copying the docs isn't very useful. I still have no idea what "disconnecting from a terminal" means.
        All the processes started from the same process share the same session and the same terminal. This is true when started with '&', run on the command-line, or fork/exec within a program.

        When setsid() ("set session id") is called we create a new session which does not have a terminal. By default, the process which calls setsid() is moved to the new session (setsid() can take a PID as a parameter). The process is now the only process in the new session, unless it starts new processes itself. It does not have a terminal and ps -ef will show ? against its TTY column. This is the usual way that a daemon disconnects from a terminal since it does not want signals from the keyboard.

        (Not copied from doc)