Quel est le but de la commande intégrée bash `suspend`?

J'ai tapé help suspendet obtenu cette courte explication:

suspend: suspend [-f]
    Suspend shell execution.

    Suspend the execution of this shell until it receives a SIGCONT signal.
    Unless forced, login shells cannot be suspended.

    Options:
      -f    force the suspend, even if the shell is a login shell

    Exit Status:
    Returns success unless job control is not enabled or an error occurs.

Voici ce que je comprends: je tape suspendet le terminal se bloque, même strg + c ne peut pas le dégeler. Mais lorsque j'ouvre un autre terminal et recherche le PID pour le gelé et que je tape, kill -SIGCONT PID-NRun signal SIGCONT est envoyé au terminal gelé et le décongèle, de sorte qu'il se dégèle.

Mais quel est le véritable objectif de la suspension d'un terminal? Quelles applications quotidiennes lui sont typiques? À quoi pensaient les gens qui en ont fait un obus intégré?

Si vous démarrez un shell à partir d'un autre shell, vous pouvez suspendre le shell interne. Dites lors de l'utilisation suet que vous souhaitez revenir à l'utilisateur normal pendant un moment:

user$ su
Password: ...
root# do something
root# suspend
user$ do something as the ordinary user again
user$ fg
root# ...

(Si vous faites cela, n'oubliez pas le shell privilégié ouvert en arrière-plan ...)

De même, si vous échappez à un shell à partir d'un autre programme (la !commande par exemple less), vous pouvez toujours suspendre le shell. Mais je ne m'attendrais pas à ce que de nombreux autres programmes le gèrent bien lorsqu'ils lancent un sous-processus, qui se suspend ensuite.

C'est l'équivalent d'appuyer Ctrl+Zsur d'autres commandes.

Il suspend le shell et redonne le contrôle au shell parent ou au processus, le cas échéant.

Exemple:

zsh$ bash
bash-4.4$ cd /
bash-4.4$ suspend
zsh: suspended (signal)  bash
zsh$ fg
[1]  + continued  bash
bash-4.4$ pwd
/

La fonctionnalité vient de csh, le shell de BSD (d'où vient le contrôle des tâches) au début des années 80 .

Dans AT&T ksh, c'est un alias intégré pour kill -s STOP $$( oui, sans les guillemets! )

Dans votre cas, bashest-ce probablement celui qui a été démarré directement par l'émulateur de terminal. Et votre émulateur de terminal ne s'attendait pas à ce que le processus soit suspendu.

C'était bashun chef de session. Si le chef de session est suspendu, si nous prenons l'avis des anciens terminaux horaires, l'utilisateur n'aura aucun moyen de le reprendre.

bashrésout cela en refusant suspends'il s'agit d'un shell de connexion. Mais dans votre cas, votre émulateur de terminal ne démarre probablement pas bashen mode connexion, de sorte que la sauvegarde n'est pas en place.

zshet mkshn'ont pas le problème car ils envoient un signal SIGTSTP(celui également envoyé sur Ctrl+Z) comme csh au lieu de SIGSTOP(et au groupe de processus de l'appelant pour mkshcomme dans csh, et au groupe de processus principal du shell pour zsh, pas le $$processus seul ). SIGTSTPest ignoré lorsqu'il est remis à un groupe de processus orphelin, et le groupe du leader est qualifié. L'idée est que SIGTSTP ne doit pas suspendre quelque chose qui ne peut pas être repris par un utilisateur.

Dans mkshou yash, on peut aussi utiliser suspendpour faire suspendre un sous-shell:

$ (set -x; sleep 1; suspend; sleep 2)
+ sleep 1
+ suspend
[1] + Stopped(SIGSTOP)     (set -x; sleep 1; suspend; sleep 2)
$ fg
[1] (set -x; sleep 1; suspend; sleep 2)
+ sleep 2

Cela ne fonctionnerait pas avec zshcela envoie le SIGTSTP au groupe de processus principal au lieu de l'appelant. Dans n'importe quel shell qui a killintégré, on peut toujours utiliser à la kill -s TSTP 0place.