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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, Feb 26, 2024 at 11:05 PM Stephane Chazelas
<stephane@xxxxxxxxxxxx> wrote:
>
> 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.

It may be that MacOS is the only one where the default is that way,
but I nearly always configure my terminal windows to create login
shells on every X11-ish desktop I use.  Further if the terminal is
running a remote shell that'll also be a login, and if you suspend a
remote shell it's rather more difficult to resume it (unless you're
using "screen" or remote tmux or something in which case you
disconnect rather than suspend the process).

> 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...).

Changing the "kill" command doesn't (in zsh at least) affect the
"suspend" command.

schaefer[592] Src/zsh -f -o login
% suspend
suspend: can't suspend login shell
% suspend -f

zsh: suspended  Src/zsh -f -o login
schaefer[593] fg
[1]  + continued  Src/zsh -f -o login
% kill -STOP $$
kill: kill 605210 failed: operation not permitted
%

I think this is more to prevent accidental stoppage?