Légèrement différent avant pour la commande `bg` dans zsh vs. bash

Question

Aujourd'hui, j'ai observé un comportement étrange sur lequel j'espère pouvoir obtenir des conseils.

Voilà ce que je fais...

Avec au moins un processus déjà en cours d'exécution en arrière-plan, j'interromps ( Ctrl + Z ) le processus de premier plan, puis le placer en arrière-plan avec bg .

Voici les résultats en zsh :

$ some-long-running-command
^Z
zsh: suspended  some-long-running-command
$ bg
[2]  - continued  some-long-running-command
$ jobs
[1]  + running    other-command-previously-run
[2]  - running    some-long-running-command
$

Et voici à quoi cela ressemble en bash :

$ other-command-previously-run &
[1] 12345
$ some-long-running-command
^Z
[2]+  Stopped                 some-long-running-command
$ bg
[2]+ some-long-running-command &
$ jobs
[1]-  Running                 other-command-previously-run &
[2]+  Running                 some-long-running-command &
$ 

Alors pourquoi bash garder le processus placé en arrière-plan avec bg comme le processus "en cours" (indiqué par "+") qui sera repris en cas d'échec. fg est exécuté), tandis que zsh définit l'"autre" processus comme actuel ? Je ne trouve aucune documentation suggérant que le comportement serait différent... Il est intéressant de noter que si vous faites plusieurs fg + ^Z + bg en zsh le choix du processus "actuel" va "basculer".

Quelqu'un d'autre a vu ça ?

Answer 1

Je peux reproduire ce comportement dans bash y zsh .

Ma réponse TL;DR : le comportement que vous observez dans bash est documenté. Le comportement que vous voyez dans zsh ne l'est pas (d'après ce que j'ai trouvé), et j'ai une théorie, qui pourrait être fausse.

---

Bash :

El Manuel de Bash La section 7, "Notions de base du contrôle des travaux", décrit le comportement de la fonction intégrée de contrôle des travaux. bg :

Les symboles '%%' et '%+' font référence à la notion de travail actuel du shell, qui est le dernier travail arrêté alors qu'il était au premier plan ou lancé en arrière-plan.

Ainsi, du point de vue de bash le emploi actuel est le dernier emploi soit arrêté au premier plan, soit démarré à l'arrière-plan. Ceci explique le comportement remarqué dans la question :

Alors pourquoi bash garde-t-il le processus placé en arrière-plan avec bg comme processus "actuel" ?

---

ZSH : Je ne peux pas l'expliquer pour zsh . Le site man zshmisc page en vertu de l'article JOBS explique ce que zsh moyens par le + y - en jobs :

%% Emploi actuel.
%+ Équivalent de '%%'.
%- Travail précédent.

Elle le fait no Cependant, expliquez quel effet bg , fg y ^Z sur les processus en les reléguant au rang de previous o current .

Mon théorie ce que je n'ai pas encore pu vérifier en harcelant les gentilles personnes de l'agence de presse. irc.freenode.net#zsh c'est que zsh utilise une "pile du processus en cours" ; bg pousse le current à la fin de la file d'attente. Ceci peut être vu en jouant avec trois processus ainsi :

simont@charmander ~/repositories/SOTesting/bg
  $ one.sh&                                                                                 [1:52:41]
[1] 98369

simont@charmander ~/repositories/SOTesting/bg
  $ two.sh&                                                                                 [1:52:49]
[2] 99293

simont@charmander ~/repositories/SOTesting/bg
  $ three.sh                                                                                [1:52:51]
^Z
[3]  + 973 suspended  three.sh

simont@charmander ~/repositories/SOTesting/bg
  $ jobs                                                                                    [1:52:55]
[1]    running    one.sh
[2]  - running    two.sh
[3]  + suspended  three.sh

simont@charmander ~/repositories/SOTesting/bg
  $ bg                                                                                      [1:52:57]
[3]  - 973 continued  three.sh

simont@charmander ~/repositories/SOTesting/bg
  $ jobs                                                                                    [1:52:59]
[1]    running    one.sh
[2]  + running    two.sh
[3]  - running    three.sh

Comme on peut le voir ici, one y two sont poussés vers le bas sur la pile théorique. three qui est exécuté en dernier est le current process dénoté par le + de la jobs sortie.
Après three est suspendu, il s'agit toujours du processus en cours, mais après que le bg il est poussé vers le previous processus et two qui est le processus "supérieur" de la "pile", devient le nouveau processus de l'entreprise. current processus.

Cependant, il s'agit d'une conjecture ; comme je l'ai dit, je n'ai pas de preuve documentée de cela, et, honnêtement, la man zsh* Les pages sont légèrement compliquées ; j'ai peut-être oublié quelque chose.