33 votes

Empêcher «bash» MSYS de tuer les processus qui piègent ^ C

J'ai une console en mode d'application Windows (porté à partir d'Unix) qui a été conçu à l'origine pour faire un nettoyage de sortie quand il a reçu ^C (Unix SIGINT). Un nettoyage de sortie dans ce cas implique d'attendre, potentiellement un temps assez long, pour les connexions réseau distant à fermer. (Je sais que ce n'est pas le comportement normal d' ^C mais je ne suis pas en mesure de le changer.) Le programme est mono-thread.

Je peux piège ^C soit avec signal(SIGINT) (comme sous Unix) ou avec SetConsoleCtrlHandler. Soit fonctionne correctement lorsque le programme est exécuté en vertu de CMD.EXE. Cependant, si j'utilise le "bash" shell qui vient avec MSYS (je suis à l'aide de l'environnement MinGW pour construire le programme, car cela me permet de réutiliser le makefile Unix), alors le programme de fermeture forcée du hasard, le temps court (moins de 100 millisecondes) après le ^C. C'est inacceptable, car comme je l'ai mentionné, le programme doit attendre les connexions réseau distant à fermer.

Il est très probable que les gens vont vouloir exécuter ce programme en vertu de la pme de bash. Aussi, cet effet sauts de la suite de test. Je n'ai pas été en mesure de trouver un moyen de contourner le problème dans le programme (idéal) ou par des paramètres sur la coquille (acceptable). Quelqu'un peut-il recommander quoi que ce soit?

1voto

Anthill Points 855

Arg - 5 minutes de modifier le commentaire. Voici ce que j'ai voulu écrire:

Comme solution de contournement, au lieu d'essayer de piéger le CTRL-C de l'événement qui est également propagée à la coque que j'avais proposer de désactiver le ENABLED_PROCESSED_INPUT sur stdin, de sorte que CTRL-C est signalé comme un clavier d'entrée au lieu de comme un signal:

DWORD mode;
HANDLE hstdin = GetStdHandle(STD_INPUT_HANDLE);
GetConsoleMode(hstdin, &mode);
SetConsoleMode(hstdin, mode & ~ENABLE_PROCESSED_INPUT); /* disable CTRL-C processing as a signal */

Vous pourriez ensuite procédé à la saisie au clavier dans votre thread principal, tandis que le reste du programme n'a son truc dans un thread séparé et définir un événement pour le nettoyage lorsque CTRL-C est reçu.

0voto

phs Points 5913

Lorsque vous exécutez votre programme avec MSYS bash, ne vous lancez l'exécutable directement, ou est-il un emballage (bash) script shell?

Si oui, il peut être l'enregistrement d'un personnalisé Ctrl-C handler avec l' trap de la commande (qui n'sommeil, suivie par une mise à mort.) Si une telle chose existe, de modifier ou de la supprimer.

Si il n'y a pas d' trap enregistrée, ou il n'y a aucun emballage script, envisager de faire un tel script et ajouter votre propre piège pour remplacer le comportement par défaut. Vous pouvez voir un exemple de comment l'utiliser ici ou sur la page de manuel de bash (dans le SHELL les builtins section).

0voto

Nulik Points 465

Ctrl-C est SIGINT? Je pensais que Ctrl-Z était SIGINT, mais Ctrl-C était SIGTERM. Regarde ça.

0voto

Anthill Points 855

Avez-vous un paramètre d'environnement CYGWIN (dans le panneau de configuration / variables d'environnement)? Essayez de définir CYGWIN = notty et redémarrez, ouvrez un nouveau shell bash MSYS - le problème persiste-t-il?

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X