J'ai un script bash qui agit comme shell par défaut pour un utilisateur se connectant via ssh. Il propose un menu avec plusieurs options, dont l'une est d'envoyer un fichier en utilisant netcat.
Le netcat de l'embedded Linux que j'utilise ne dispose pas de l'option -w, donc si l'utilisateur ferme la connexion ssh sans jamais envoyer le fichier, la commande netcat attend indéfiniment.
Je dois savoir si l'utilisateur ferme brusquement la connexion afin que le script puisse tuer la commande netcat et quitter proprement.
Les choses que j'ai déjà essayées:
- Piéger le signal SIGHUP: il n'est pas émis. Le seul signal émis que j'ai pu trouver est SIGCONT, mais je ne pense pas que ce soit fiable et portable.
- Jouer avec l'option -t de la commande read pour détecter une fermeture de stdin: cela fonctionnerait si ce n'était pas pour un bogue stupide dans la commande read intégrée (n'expire qu'à la première invocation)
Éditer:
Je vais essayer de répondre aux questions dans les commentaires et expliquer la situation plus en détail.
Le code que j'ai est:
nc -l -p 7576 > /dev/null 2>> $LOGFILE < $TMP_DIR/$BACKUP_FILE &
waitJ'ignore SIGINT et SIGTSTP, mais j'ai essayé de piéger tous les signaux et le seul reçu est SIGCONT.
En lisant la page de manuel de bash, j'ai découvert que le SIGHUP devrait être envoyé à la fois au script et à netcat et que le SIGCONT est envoyé aux travaux arrêtés pour s'assurer qu'ils reçoivent le SIGHUP.
Je suppose que le wait fait en sorte que le script soit considéré comme arrêté et qu'il reçoive le SIGCONT, mais en même temps, le wait semble absorber le SIGHUP.
J'ai donc essayé de remplacer le wait par un sleep, et alors à la fois le SIGHUP et le SIGCONT sont reçus.
La question est: pourquoi le wait bloque-t-il le SIGHUP?
Éditer 2 : Résolu
J'ai résolu le problème en vérifiant une fermeture de stdin avec la commande intégrée read utilisant l'option -t. Pour contourner le bogue de la commande read intégrée, je la lance dans un nouveau bash (bash -c "read -t 3 dummy").
