Voici la séquence de commandes, gedit démarre, mais il ne peut pas être tué à partir de son ID de processus

$ gedit&
$ t=$!
$ echo $t
4824
$ kill $t
bash: kill: (4824) - No such process

Cela fonctionnerait très bien pour un sleep processus, comme

sleep 999&
[1] 4881
$ t=$!
$ echo $t
4881
$ kill $t
$ ps -p $t
[1]   Terminated              sleep 999

Quelle est la différence? Comment le gedit peut-il le processus doit-il être terminé ?

Réponse acceptée :

Le gedit processus est déjà résilié.

Rappelez-vous comment les applications Windows fonctionnaient principalement à l'époque de Win16 avant que Win32 n'arrive et ne s'en débarrasse :où il y avait hInstance et hPrevInstance , tenter d'exécuter une deuxième instance de nombreuses applications a simplement remis les choses à la première instance, et cela a rendu les choses difficiles pour les outils de script de commande (comme Take Command) car on invoquait une application une deuxième fois, elle serait visiblement là sur le screen en tant que fenêtre ajoutée, mais en ce qui concerne l'interpréteur de commandes, le processus enfant qu'il venait d'exécuter s'est immédiatement arrêté ?

Eh bien, GNOME a ramené le comportement Win16 pour Linux.

Avec les applications GIO comme gedit , l'application se comporte comme suit :

• S'il n'y a pas de "serveur" enregistré nommé org.gnome.gedit déjà sur le bus de bureau par utilisateur/par connexion, gedit décide que c'est la première instance. Cela devient le org.gnome.gedit serveur et continue de s'exécuter.
• S'il existe un "serveur" enregistré nommé org.gnome.gedit déjà sur le bus de bureau par utilisateur/par connexion, gedit décide qu'il s'agit d'une deuxième instance ou d'une instance ultérieure. Il construit des messages de bus de bureau à la première instance, transmettant ses options et arguments de ligne de commande, puis quitte simplement .

Donc, ce que vous voyez dépend si vous avez le gedit serveur déjà en cours d'exécution. Si ce n'est pas le cas, vous serez à la place de Sebvieira et vous vous demanderez pourquoi vous ne voyez pas le comportement décrit. Si c'est le cas, vous serez à votre place et verrez le gedit processus se terminant presque immédiatement, d'autant plus que vous ne lui avez pas donné d'options de ligne de commande ou d'arguments à envoyer à la "première instance". D'où la raison pour laquelle il n'y a plus de processus avec cet ID.

Beaucoup de plaisir s'ensuit lorsque, comme évoqué ci-dessus, le bus de bureau par connexion passe au «nouveau» style d'un bus de bureau par utilisateur, et tout à coup il n'y a plus de relation 1:1 entre un bus de bureau et un affichage X Suite. Les applications d'instance utilisateur unique à l'échelle du bus doivent soudainement être capables de communiquer simultanément avec plusieurs écrans X.

Une autre hilarité s'ensuit lorsque les gens tentent d'exécuter gedit en tant que superutilisateur via sudo , car soit il ne peut pas se connecter à un bus de bureau par utilisateur, soit il se connecte au mauvais bus de bureau (celui du superutilisateur).

En relation:Comment chmod sans /usr/bin/chmod ?

Il y a une proposition pour donner gedit une option de ligne de commande qui fait en sorte que le processus invoqué soit simplement l'application d'édition réelle , de sorte que gedit serait utile en tant qu'éditeur pointé par le EDITOR variable d'environnement (ce qui n'est pas le cas pour de nombreuses utilisations courantes de EDITOR , de crontab à git , lorsqu'il se ferme immédiatement). Cette proposition n'est pas encore devenue réalité.

En attendant, les gens ont différentes façons d'avoir une simple deuxième instance d'un "éditeur de texte léger", comme l'appel d'une toute nouvelle instance de Desktop Bus, privée à l'invocation de gedit , avec dbus-run-session . Bien sûr, cela a tendance à faire tourner d'autres serveurs GNOME Desktop Bus sur ce bus privé car ils sont à leur tour invoqués par gedit , ce qui le rend pas du tout "léger".

La cerise sur le gâteau, c'est quand vous avez suivi cette recommandation ou une autre similaire et interposé une fonction shell nommée gedit qui supprime immédiatement le gedit processus à partir de la liste des tâches du shell. Non seulement le processus se termine rapidement afin que vous ne le revoyiez pas plus tard avec kill ou ps , mais le shell ne le surveille même pas en tant que tâche contrôlée par le shell.

Autres lectures

• Apps/Gedit/NouvelleInstance Unique. Wiki GNOME. 2013.
• "Description". GApplication . Wiki des développeurs GNOME.
• https://stackoverflow.com/questions/7553452/
• Stefan Löffler (2011-05-04). ne réutilise pas l'instance en cours d'exécution lorsqu'elle est démarrée à partir de nautilus. Bogue #777292. Barre de lancement.