Déplacer un programme démarré dans l'écran GNU vers un autre terminal

Je veux terminer une instance de GNU screentout en préservant le processus en cours d'exécution à l'intérieur.

J'ai donc ouvert mon programme d'émulation de terminal normal et exécuté l'écran. Ensuite, j'ai utilisé cette instance de screenpour exécuter ./script_x.sh. Maintenant, pour une raison quelconque, je veux arrêter d'utiliser screenmais script_x.shn'a pas encore terminé sa tâche et je ne suis pas prêt à renoncer à mes progrès.

Puis-je garder le processus actif en vie afin de continuer à y travailler à l'intérieur de mon émulateur de terminal normal?

— voix
source

Voulez-vous vraiment tuer l'écran ou vous en détacher? L'écran est destiné à être utilisé pour exécuter un processus en arrière-plan afin que vous puissiez continuer dans votre session normale, il permet également aux applications de continuer à fonctionner après votre déconnexion (par exemple, déconnectez votre session SSH). Vous pouvez toujours vous détacher de l'écran, continuer dans votre session normale et reprendre là où vous vous êtes arrêté dans la session écran. Votre émulateur de terminal n'a rien à voir avec cela.

— BlueCacti

Ou créez simplement un autre écran dans la screensession.

— chrylis -on strike-

Cette question sent le problème XY .

— Digital Chris

@ tjt263 - vous dites que vous regrettez d'utiliser screen en premier lieu, alors que feriez-vous pour que votre processus continue si vous n'aviez pas utilisé screen? Vous pouvez toujours faire la même chose avec le processus dans screen, mais screen a l'avantage supplémentaire que vous pouvez vous en détacher et laisser votre processus s'exécuter sans être dérangé.

— Johnny

@DigitalChris Cela pourrait faire maintenant. J'ai l'impression que le titre original était probablement plus pertinent. Il y a 3 points distincts: j'exécutais un programme à l'intérieur screen. Je voulais arrêter d'utiliser screen. Je ne voulais pas arrêter le programme qui s'exécutait à l'intérieur screen. C'est ça. Je ne sais pas comment clarifier la situation ou l'exprimer plus simplement que cela.

— voix

Réponses:

TLDR: Réponse pratique: Non.

Réponse plus longue:

En théorie, vous le pouvez. Si vous avez commencé quelque chose comme nohup myprog &à l'intérieur de l'écran, il continuera de fonctionner. Il ignorera un signal de raccrochage et n'aura aucune entrée, mais en théorie, vous pouvez continuer à travailler avec lui.

En pratique, ce n'est pas le cas. Ainsi, sauf si vous voulez attacher un débogueur au processus en cours et réécrire ses descripteurs de fichiers et vous assurer que le processus gère les signaux -1 lorsque vous fermez l'écran ... alors la réponse est non.

Si vous êtes prêt à le faire, j'ai un signet à la maison indiquant [SU] où quelqu'un a fait exactement cela . Enregistré pour la génialité, pas parce que c'est facile et trivial à faire.

— Hennes
source

Notez que la question a été modifiée massivement depuis votre réponse.

— chrylis -on strike-

La déconnexion d'un processus est assez simple - il s'agit de définir des groupes de processus (avec disownou à un niveau inférieur) afin qu'aucun SIGHUPne soit envoyé lorsque le processus parent est mort. La reconnexion des E / S est une autre chose - c'est là que le débogueur entre en jeu.

— Alexis

Vous n'avez pas besoin nohupsi vous êtes dans une coquille de contrôle de l' emploi (comme bash, ksh, csh, zsh, ash, etc.). Si vous utilisez toujours un shell de contrôle autre que Job comme Bourne, shil est peut-être temps de mettre à niveau.

— poussins

Vous pouvez essayer d'utiliser reptyrpour rattacher l'application déjà en cours d'exécution à un autre terminal. Cependant, il a quelques problèmes avec l'envoi du processus en arrière-plan.

Je viens de le tester (démarrer à l' htopintérieur screen, reptyrvers un autre terminal, tuer screen), et cela semblait bien fonctionner. C'est toujours une solution vraiment hacky, donc aucune garantie.

— un terrain
source

Moins hacky que d'utiliser gdb :)

— Hennes

Oui (si "tuer" ne tue pas vraiment), c'est en fait exactement à cela que sert l'écran. Vous devriez vérifier le manuel et essayer celui qui correspond à vos besoins:

C-a d
C-a C-d     (detach)      Detach screen from this terminal.

C-a D D     (pow_detach)  Detach and logout.

Ensuite, vous aurez besoin des options de ligne de commande -D / -d -R / -r de l'écran, selon votre choix.

— Gombai Sándor
source

Cela ne répond pas à la question. L'OP ne veut pas se détacher de l'écran, il veut mettre fin au processus d'écran.

— Guntram Blohm prend en charge Monica

Oui, il l'a écrit mais je ne suis pas sûr qu'il ait demandé ce qu'il voulait.

— Gombai Sándor

@GuntramBlohm Il n'est pas du tout clair que l'OP comprenne comment fonctionne l'écran, et c'est l'effet le plus probable souhaité.

— chrylis -on strike-

Savez-vous que l'écran n'est pas un terminal différent de xterm mais une couche (un pseudo terminal) qui peut être attachée à votre terminal réel (vterm, xterm, terminator, (m) rxvt, any) après l'avoir détaché de tout autre terminal? Et l'écran est ce qui maintient votre processus en cours d'exécution, vous l'avez démarré à l'intérieur de l'écran (et il le fait bien). Si vous tuez (vraiment tuez) l'écran, alors vous retirez le tapis de sous votre processus ... Je ne vois pas de bonne raison pour laquelle vous le feriez.

— Gombai Sándor

@ GombaiSándor: Une raison de vouloir le faire serait de faire en sorte que le processus parle directement à un terminal afin de passer à travers des capacités que l'écran ne connaît pas. Par exemple, j'ai piraté une fois ma propre version de xterm pour que toutes les touches de fonction étranges de mon clavier envoient des séquences d'échappement qui comprenaient le X11 keysym et l'état de modification complet, au lieu d'essayer de prétendre qu'il s'agissait d'un VT102 - puis j'ai commencé à installer raccourcis clavier pour eux dans emacs. Ces séquences ne passeraient pas indemnes à l'écran.

— Henning Makholm