Passing the shell to a child before aborting

Current scenario, I launch a process that forks, and after a while it aborts().

The thing is that both the fork and the original process print to the shell, but after the original one dies, the shell "returns" to the prompt.

I'd like to avoid the shell 开发者_如何学运维returning to the prompt and keep as if the process didn't die, having the child handle the situation there.

I'm trying to figure out how to do it but nothing yet, my first guess goes somewhere around tty handling, but not sure how that works.

I forgot to mention, the shell takeover for the child could be done on fork-time, if that makes it easier, via fd replication or some redirection.

I think you'll probably have to go with a third process that handles user interaction, communicating with the "parent" and "child" through pipes.

You can even make it a fairly lightweight wrapper, just passing data back and forth to the parent and terminal until the parent dies, and then switching to passing to/from the child.

To add a little further, as well, I think the fundamental problem you're going to run into is that the execution of a command by the shell just doesn't work that way. The shell is doing the equivalent of calling system() -- it's going to wait for the process it just spawned to die, and once it does, it's going to present the user with a prompt again. It's not really a tty issue, it's how the shell works.

bash (and I believe other shells) have the wait command:

wait: wait [n]

Wait for the specified process and report its termination status. If N is not given, all currently active child processes are waited for, and the return code is zero. N may be a process ID or a job specification; if a job spec is given, all processes in the job's pipeline are waited for.

Have you considered inverting the parent child relationship?

If the order in which the new processes will die is predictable, run the code that will abort in the "child" and the code that will continue in the parent.