append forgotten "&", without "^Z bg" lurch
jid...@jidanni.org
But that means my program must grind to a halt for the time, ever so
small perhaps, between when I hit the ^Z and "bg".
No big deal you say. "Just open another window and never mind the old one".
Fair enough. But I'm just curious. Is there any way to get back to the
shell session without having to cause my program to lurch to a
screeching halt, though ever so momentarily.
Please don't tell me to type anything different. It's too late. The
program has already started, and I want to "append the "&" that I forgot".
(kill(1): I bet I would have to send two signals too.)
SHELL=/bin/bash.
Janis Papanagnou
I suppose it's not possible from the shell level to avoid sending _two_
signals. But at least you could send SIGSTOP and SIGCONT to your process
in a single shell command sequence...
pid=whatever
kill -STOP $pid && kill -CONT $pid
(Don't get irritated about the "Stopped (SIGSTOP)" message.)
Janis
pk
Will that resume $pid in the background, as the OP wants? My understanding
is that the above commands will resume $pid in the foreground, just as it
was before.
Janis Papanagnou
In a test shell program I've sent the signals to the shell executing
the script, and it works as described. If I do the same and send the
signal to an executable then the shell does not get control. Though,
in the latter case I could achieve it by
kill -STOP $pid ; sleep 0; kill -CONT $pid
which will keep the executable running and you will keep interactive
terminal control on your shell.
Janis
pk
>>>I suppose it's not possible from the shell level to avoid sending _two_
>>>signals. But at least you could send SIGSTOP and SIGCONT to your process
>>>in a single shell command sequence...
>>>
>>>pid=whatever
>>>kill -STOP $pid && kill -CONT $pid
>>
>>
>> Will that resume $pid in the background, as the OP wants? My
>> understanding is that the above commands will resume $pid in the
>> foreground, just as it was before.
>
> In a test shell program I've sent the signals to the shell executing
> the script, and it works as described. If I do the same and send the
> signal to an executable then the shell does not get control. Though,
> in the latter case I could achieve it by
>
> kill -STOP $pid ; sleep 0; kill -CONT $pid
>
> which will keep the executable running and you will keep interactive
> terminal control on your shell.
In my case, it seems I have to use this last form even for a shell running a
script.
Thank you!
Janis Papanagnou
Hmm.. - interesting. I suspect there's a race condition involved, and
some more tests showed that a "0 sec" interrupt might not be sufficient
with binaries as well to work reliably, larger values might be necessary;
so use that approach with some care!
Janis
> Thank you!
>