Comment créer une window X qui ne se fermera pas d'une manière autre qu'une command de terminal

Si le passage à xterm est une option, vous pouvez utiliser le hack ci-dessous. Il y a cependant quelques mises en garde. Une fois que vous répondez à la plupart d'entre eux, la solution finit par se compliquer, voir le script final à la fin.

 xterm -e 'trap "" HUP; your-application' 

A la réception de l'instruction de fermeture du gestionnaire de windows, xterm enverra un SIGHUP au groupe de process de votre application et ne se quittera que lorsque le process sera rétabli.

Cela suppose que votre application ne réinitialise pas le gestionnaire pour SIGHUP et pourrait avoir des effets secondaires indésirables pour les enfants de votre application.

Les deux semblent être un problème si votre application est tmux .

Pour contourner ceux-ci, vous pourriez faire:

 xterm -e sh -c 'bash -mc tmux <&1 & trap "" HUP; wait' 

De cette façon, tmux serait lancé dans un groupe de process différent, de sorte que seul le sh recevrait le SIGHUP (et l'ignorer).

Cela ne s'applique pas à tmux qui réinitialise le gestionnaire pour ces signaux, mais dans le cas général, en fonction de votre implémentation de sh , les signaux SIGINT, SIGQUIT et généralement les deux seront ignorés pour votre application car ce bash est démarré comme une command asynchronous à partir d'un sh non-interactif. Cela signifie que vous ne pouvez pas interrompre votre application avec Ctrl + C ou Ctrl + \ .

C'est une exigence POSIX. Certains shells comme mksh ne l'honorent pas (du less pas les versions actuelles), ou seulement en partie comme dash qui le fait pour SIGINT mais pas SIGQUIT. Donc, si mksh est disponible, vous pourriez faire:

 xterm -e mksh -c 'bash -mc your-application <&1 & trap "" HUP; wait' 

(bien que cela puisse ne pas fonctionner dans les futures versions de mksh s'ils décident de corriger cette non-conformité).

Ou si vous ne pouvez pas garantir que mksh ou bash sera disponible ou préférez ne pas countr sur un comportement qui pourrait changer à l'avenir, vous pouvez faire leur travail à la main avec perl et par exemple écrire un script wrapper unclosable-xterm comme:

 #! /bin/sh - [ "$#" -gt 0 ] || set -- "${SHELL:-/bin/sh}" exec xterm -e perl -MPOSIX -e ' $pid = fork; if ($pid == 0) { setpgrp or die "setpgrp: $!"; tcsetpgrp(0,getpid) or die "tcsetpgrp: $!"; exec @ARGV; die "exec: $!"; } die "fork: $!" if $pid < 0; $SIG{HUP} = "IGNORE"; waitpid(-1,WUNTRACED)' "$@" 

(pour être appelé unclosable-xterm your-application and its args ).

Un autre effet secondaire est que ce nouveau groupe de process que nous créons et mettons en avant-plan (avec bash -m ou setpgrp + tcsetpgrp ci-dessus) n'est plus le groupe de process leader de session, donc plus un groupe de process orphelins soi-disant soigné maintenant ( sh ou perl )).

Cela signifie que lorsque vous appuyez sur Ctrl + Z , ce process sera suspendu. Ici, notre parent insouciant va juste quitter, ce qui signifie que le groupe de process obtiendra un SIGHUP (et j'espère mourir).

Pour éviter cela, nous pourrions simplement ignorer le SIGTSTP dans le process enfant, mais si votre application est un shell interactif, Ctrl-Z ne fonctionnera pas pour les tâches exécutées pour certaines implémentations comme mksh , yash ou rc .

Ou nous pourrions mettre en place un parent plus prudent qui reprend l'enfant chaque fois qu'il est arrêté, comme:

 #! /bin/sh - [ "$#" -gt 0 ] || set -- "${SHELL:-/bin/sh}" exec xterm -e perl -MPOSIX -e ' $pid = fork; if ($pid == 0) { setpgrp or die "setpgrp: $!"; tcsetpgrp(0,getpid) or die "tcsetpgrp: $!"; exec @ARGV; die "exec: $!"; } die "fork: $!" if $pid < 0; $SIG{HUP} = "IGNORE"; while (waitpid(-1,WUNTRACED) > 0 && WIFSTOPPED(${^CHILD_ERROR_NATIVE})) { kill "CONT", -$pid; }' "$@" 

Un autre problème est que si xterm disparu pour une autre raison que la fermeture du gestionnaire de windows, par exemple si xterm est tué ou perd la connection au server X (à cause de xkill , l'action de destruction de votre gestionnaire de windows ou du server X crashes par exemple), alors ces process ne mourront pas car SIGHUP serait également utilisé dans ces cas pour les terminer. Pour contourner cela, vous pouvez utiliser poll() sur le terminal (qui serait démoli quand xterm va):

 #! /bin/sh - [ "$#" -gt 0 ] || set -- "${SHELL:-/bin/sh}" exec xterm -e perl -w -MPOSIX -MIO::Poll -e ' $pid = fork; # start the command in a child process if ($pid == 0) { setpgrp or die "setpgrp: $!"; # new process group tcsetpgrp(0,getpid) or die "tcsetpgrp: $!"; # in foreground exec @ARGV; die "exec: $!"; } die "fork: $!" if $pid < 0; $SIG{HUP} = "IGNORE"; # ignore SIGHUP in the parent $SIG{CHLD} = sub { if (waitpid(-1,WUNTRACED) == $pid) { if (WIFSTOPPED(${^CHILD_ERROR_NATIVE})) { # resume the process when stopped # we may want to do that only for SIGTSTP though kill "CONT", -$pid; } else { # exit when the process dies exit; } } }; # watch for terminal hang-up $p = IO::Poll->new; $p->mask(STDIN, POLLERR); while ($p->poll <= 0 || $p->events(STDIN) & POLLHUP == 0) {}; kill "HUP", -$pid; ' "$@" 

Votre question a un titre quelque peu trompeur, menant votre search dans la mauvaise direction. Lorsque vous fermez une window dans X , le server ne tue pas votre process . Au lieu de cela, il envoie un message WM_DELETE_WINDOW au process, qui à son tour se termine. Ce fait condamne votre première approche: même si vous définissez le drapeau SIGNAL_UNKILLABLE , vous pourrez toujours le fermer.

Votre deuxième approche semble utilisable, tout ce que vous avez à faire est de discriminer une window de terminal unique contre tous les autres. Une façon d'y parvenir est de lancer urxvt avec un titre particulier, par exemple urxvt -name urxvt-iddqd , et créer une règle pour son nom:

 <keybind key="A-F4"> <action name="If"> <application title="urxvt-iddqd" title="tmux-session"> </application> <then><!-- Do nothing for urxvt-tmux-session --></then> <else> <action name="Close" /> </else> </action> </keybind>