Re: "kill -STOP" as noticed in ksh93u+ gitlab

[Stephane Chazelas <stephane@xxxxxxxxxxxx>]

2024-02-26 13:26:37 -0800, Bart Schaefer:
> > The kill built-in command now correctly refuses to issue SIGSTOP to the shell's own process if the shell is a login shell.
> 
> Is this something we should consider for zsh?

Commit log gives more info:

> commit 8cc9a13deb3b29e30849d6c6c1cd4a48c5d2eb53
> Author: Martijn Dekker <martijn@xxxxxxxx>
> Date:   Sat Sep 16 01:17:13 2023 +0100
> 
>     job_kill(): fix bogus assumption that login shell has PPID 1
> 
>     Normally, suspending a login shell with SIGSTOP (e.g., kill -STOP
>     $$) will irrecoverably freeze the terminal session, so it is a good
>     idea to prohibit that.
> 
>     But job_kill() (called via the 'kill' built-in, b_kill()) assumes
>     that any login shell has a parent PID of 1, a.k.a. init. This may
>     have been valid on some systems back in the 1980s, but when people
>     started using graphical terminals (if not before), that assumption
>     became universally bogus.
> 
>     Some shells (at least yash) prohibit issuing SIGSTOP to self if
>     their process is the session leader. But even that doesn't always
>     hold. For instance, on macOS, the terminal creates a login(1)
>     process (the session leader), and the login shell is its child.
> 
>     So really the only thing we can reliably do is check for the
>     -l/--login/SH_LOGIN_SHELL shell option (as the 'suspend' built-in
>     already does; see 3ba4900e).

(also note that suspend used to be an alias to kill -STOP $$
(yes, without the quotes around the expansion) in ksh93).

So that's about extending an old (obsolete) behaviour to
graphical terminal emulators and only for macos which is the
only system that I've heard of where terminal emulators create a
login shell.

But, that seems wrong. It made sense in the 80s where if you
froze your login session, you would have no chance to recover
from it. But in the graphical emulator case, you could envisage
one wanting to suspend their shell (login or not) and resume it
later with a SIGCONT from another shell (in a different terminal
emulator or different ssh session...).

And doing that for login shells makes less sense than for
session leaders especially considering it's even easier now to
start a login shell with zsh --login or ARGV0=-zsh zsh.

I've not seen any other shell that does that.

-- 
Stephane