What makes Ctrl-Z different from kill -STOP, and how can I get the behavior of the former in a shell script?
CTRL-Z usually sends SIGTSTP (which can be blocked), and - apart from other things - shells often reset tty to a previously saved state on these occasions. More importantly however, the controlling terminal process group is set to the shell's PID (and then again to a PID of a job resumed with fg).
Back to your original problem: using a temperature dependent frequency scaling like e.g. Cpufreqd might be actually a better hammer for your nail.
This is not possible.
Well, it is if you are prepared to muck around with a debugger, and poke the internals of the process running your shell program. So more specifically: this is not possible in a simple straightforward manner at the level of shell programming.
This is because disown affects a list of "jobs" that the shell program maintains in the memory space of each individual shell process.
Shells (job control ones, that is) remember the child processes that they forked in their internal "job tables", until they are instructed to forget about them by disown or the child processes terminate and the shell has wait()ed for them and reported the termination of the "job". disown does not affect the child process state in any way. It affects what the shell does.
Because it forgets about the disowned process …
- … it no longer recognizes the completion of a "job" when
wait() informs it about the termination of the child;
- … it no longer cares if the process is still running when it is told to
exit/logout; and
- … it no longer sends a hangup signal to the child when it receives a hangup signal itself (or, in the case of some shell programs, when it exits and it knows that it is an interactive login shell).
Shells do not share these lists, and they are not easily accessible (sans, as mentioned, firing up a debugger and attaching it) from other processes. There is no IPC mechanism or command-line tool for accessing them except for the built-in disown command run within the relevant shell process itself. (This is why it is a built-in command.)
This is why you cannot even disown jobs from a second shell even within the same login session. disown is entirely a per-shell per-shell-process thing.
Furthermore …
Putting the process in background from another shell is possible.
Actually, that is not what you've been doing.
The notion of foreground and background are relative to the controlling terminal of the session. Specifically, there is one process group, known to the controlling terminal, that is the foreground process group. Stopping and continuing processes does not by itself switch processes between foreground and background. One needs to update the controlling terminal's foreground process group as well. A foreground process is only in the foreground by dint of being a member of that foreground process group. All other process groups in that session, and thus processes in those process groups, are in the background.
Ironically, you haven't been doing this from another shell. What you've been doing is triggering the original shell process to take action. It sees the main process of the foreground process group stop, and it adjusts the terminal's foreground process group (back to its own process group) in response.
The right signal is SIGTSTP, by the way.
Further reading
Best Answer
Having a global keybind to disown the foreground process is impossible: Keystrokes are received by the foreground process, not by the shell. You need to first suspend it with Ctrl+z if you want to disown it.
However, turns out there's a zsh option to speed up disowning then continuing: With
setopt AUTO_CONTINUE,disownwill automatically also sendSIGCONT.So you can get it down to
C-zdisown.