Rediriger Ctrtl+C vers le programme lancé par le shell

Version imprimable

09/12/2016, 08h31
Bktero

Rediriger Ctrtl+C vers le programme lancé par le shell
Bonjour,

J'ai un script bash qui fait ceci :
```
#!/bin/bash
nohup mspdebug rf2500 gdb &
msp430-gdb a.out --command=command.gdb
```
La première commande lance un GDB proxy (équivalent à un GDB serveur ?), la second lance un GDB qui se connecte au proxy pour débogguer la cible (qui est une carte électronique avec un MCU : http://www.ti.com/tool/msp-exp430g2). Mon script GDB lance l'exécute du programme et je dois faire Ctrl+C pour mettre en pause.

Si je lance ces 2 commandes séparément et manuellement depuis mon terminal, c'est OK. En revanche, en lançant ces commandes via ce script bash, le Crtl+C termine le script au lieu de mettre mon programme en pause, c'est pas OK !

Ma question est donc : comment rediriger Ctrtl+C vers le GDB lancé par le script ?

Merci d'avance ! :ccool:
09/12/2016, 09h41
Jipété

https://www.cyberciti.biz/faq/unix-l...able-controlc/
et avec un exemple :
http://www.unix.com/shell-programmin...ll-script.html

Hum...

Si j'ai bien compris, Bktero ne veut pas que le script ignore le ctrl-c (signal SIGINT = 2), mais plutôt le transmettre au programme lancé par le script.

Je ne suis pas un expert de ce genre de truc, mais il me semble qu'il faudrait plutôt faire quelque chose comme ceci (non testé):
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 #!/bin/bash # trap ctrl-c and call the ctrl_c function trap ctrl_c INT # This is what should be done when ctrl-c occurs function ctrl_c() { echo "** Trapped CTRL-C" kill -SIGINT ${gdb_pid} } nohup mspdebug rf2500 gdb & msp430-gdb a.out --command=command.gdb & # Get the pid of the last background process (the gdb process) gdb_pid=$! # Wait for children to finish wait

09/12/2016, 11h29
Jipété

Citation:

Envoyé par jack-ft

Hum...

Si j'ai bien compris, Bktero ne veut pas que le script ignore le ctrl-c (signal SIGINT = 2), mais plutôt le transmettre au programme lancé par le script.

Oh lala oui, je suis confus, :oops: j'ai lu trop vite, vraiment désolé et merci de corriger mes erreurs/horreurs, où y-aurait-il un trou de souris pour que j'aille m'y cacher ?

Vraiment vraiment désolé,

Citation:
Envoyé par jack-ft
Je ne suis pas un expert de ce genre de truc, mais il me semble qu'il faudrait plutôt faire quelque chose comme ceci (non testé):
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 #!/bin/bash # trap ctrl-c and call the ctrl_c function trap ctrl_c INT # This is what should be done when ctrl-c occurs function ctrl_c() { echo "** Trapped CTRL-C" kill -SIGINT ${gdb_pid} } nohup mspdebug rf2500 gdb & msp430-gdb a.out --command=command.gdb & # Get the pid of the last background process (the gdb process) gdb_pid=$! # Wait for children to finish wait
Bonjour

Super exemple (surtout pour un non-expert). Malheureusement ça ne fonctionne pas (mais ce n'est pas de ta faute car tout est nickel).

Donc moi j'ai testé parce que ça me plaisait et que je voulais le voir tourner. Voici ce que j'ai écrit

Programme "fils.sh"
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 #!/bin/bash ctrl() { echo fils ok } trap ctrl 2 echo "Je suis le fils pid=$$" i=0 while test $i -lt ${1:-20}; do i=$(($i + 1)) echo "i=$i (pid=$$)" sleep 1 done
Jusque là pas de souci. Je lance ./fils.sh et je peux taper à loisir "ctrl-c" dans ma console, je vois bien le "fils ok" apparaitre à chaque fois. Puis au bout de 20 itérations le fils s'arrête.

Maintenant je veux lancer le fils avec ta méthode. J'écris donc le code suivant

Programme "pere.sh"
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 #!/bin/bash ctrl() { echo "pere ok (fils=$pp)" kill -2 $pp } trap ctrl 2 echo "Je suis le père pid=$$" ./fils.sh 100 & pp=$! echo "pid fils=$pp" wait
Ben là ça ne fonctionne pas. Je veux dire que si je lance le père, je vois bien le pid du fils mais déjà le "ctrl-c" ne fonctionne qu'une seule fois (je ne vois qu'une fois apparaitre "pere ok (fils=xxxx)". Ensuite, plus rien toutefois le fils continue à afficher son compteur. Et en faisant un ps je vois que le père a disparu (le fils est rattaché au init). A ce niveau, je me dis que comme ça fonctionne avec le fils et sa boucle mais pas avec le père et son wait, je remplace alors le père par ceci:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 #!/bin/bash ctrl() { echo "pere ok (fils=$pp)" kill -2 $pp } trap ctrl 2 echo "Je suis le père pid=$$" ./fils.sh 100 & pp=$! echo "pid fils=$pp" while ps -fu $LOGNAME |awk '{print $2}' |grep "$pp" 1>/dev/null; do sleep 5 done wait echo "fils terminé"
Là, le père reste en vie quand je tape "ctrl-c" mais je ne vois pas apparaitre le message correspondant au "ctrl-c" (kill -2) dans le fils. Toutefois le kill part bien car si je tape "ctrl-c" quand le fils a fini mais pendant que le père est encore dans son sleep 5 je vois un message type "kill (xxxx): aucun processus de ce type". Donc le kill part bien mais il ne semble pas reçu par le fils. Vérifions cette hypothèse avec ce fils
Code:

1 2 3 4 5 6 7 8 9 #!/bin/bash echo "Je suis le fils pid=$$" i=0 while test $i -lt ${1:-20}; do i=$(($i + 1)) echo "i=$i (pid=$$)" sleep 1 done
Effectivement là le fils ne se protège contre rien. Toutefois il ne s'arrête pas quand le père lui envoie un kill -2.

A ce niveau là je reste sec. Pourtant ton exemple initial était exemplaire et correspondait bien à ce qui est écrit concernant trap et kill. Je pense que c'est à cause du trap du père qui inhibe le trap du fils...

Désolé Bktero, je ne vois pas comment résoudre ton souci...:(

J'ai tenté de mettre un place l'astuce de jack-ft mais sans succès :(

Voici mon script :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#!/bin/bash
 
# Trap SIGINT (CTRL+C) to avoid stopping the script and redirect it to GDB
trap ctrl_c INT
 
function ctrl_c() {
    echo "** Trapped CTRL+C, redirecting it to ${pid_gdb}"
    killall -INT ${pid_gdb}	
}
 
# Run mspdebug as GDB proxy
mspdebug rf2500 gdb 1>/dev/null 2>&1 &
 
pid_mspdebug=$!
echo "mspdebug is running with PID ${pid_mspdebug}"
 
# Run GDB
msp430-gdb a.out --command=command.gdb --quiet
pid_gdb=$!
echo "gdb is running with PID ${pid_gdb}"
 
# Wait for GDB completion
wait ${pid_gdb}
echo "dgb has ended, waiting for mspdebug..."
wait ${pid_mspdebug}
echo "mspdebug has ended, script exits"

Quand je lance ce script depuis un premier terminal, la session de debug se lance. Depuis un second terminal, je fais killall msp430-gdb -INT et le GDB se met correctement en pause. En revanche, si je fais un CRTL+C depuis le premier terminal, voici ce qui se passe :

$./debug.bash

mspdebug is running with PID 7396
Reading symbols from /home/pgradot/Documents/GitHub/Planteur/launchpad/a.out...done.
_reset_vector__ () at /build/buildd/gcc-msp430-4.6.3~mspgcc-20120406/./gcc-4.6.3/gcc/config/msp430/crt0.S:105
105	/build/buildd/gcc-msp430-4.6.3~mspgcc-20120406/./gcc-4.6.3/gcc/config/msp430/crt0.S: No such file or directory.
	in /build/buildd/gcc-msp430-4.6.3~mspgcc-20120406/./gcc-4.6.3/gcc/config/msp430/crt0.S
Breakpoint 1 at 0xfb08
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
Remote connection closed
thread.c:79: internal-error: inferior_thread: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
thread.c:79: internal-error: inferior_thread: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
** Trapped CTRL+C, redirecting it to 
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
./debug.bash: line 18:  7397 Aborted                 (core dumped) msp430-gdb a.out --command=command.gdb --quiet
gdb is running with PID 7396
dgb has ended, waiting for mspdebug...
mspdebug has ended, script exits

Je ne sais pas si c'est un problème de ce portage de gdb ou un problème de mon script... Des idées ?

10/12/2016, 14h34
disedorgue
Bonjour,

Peut-être que la solution suivante fonctionnerait (pas testé):
Code:

1 2 3 4 #!/bin/bash nohup mspdebug rf2500 gdb & sleep 1 exec msp430-gdb a.out --command=command.gdb
Le sleep est là juste pour temporiser histoire d'attendre que le chargement du contexte de la commande nohup... soit au moins initiée avant de lancer la commande exec qui écrasera le contexte du script bash pour le remplacer par celui de la commande msp430-gdb

@Sve@r : Pour que cela fonctionne avec le signal SIGINT, il faut désactiver le monitoring de process du bash sinon le signal n'est pas pris en compte par les process lancés en background dans les scripts.
Voici un exemple de pere.sh qui fonctionne:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 #!/bin/bash -m ctrl() { echo "pere ok (fils=$pp)" kill -2 $pp } trap ctrl 2 echo "Je suis le père pid=$$" ./fils.sh 20 & pp=$! echo "pid fils=$pp" #Remplacement du wait while jobs "%./fils.sh" >/dev/null 2>&1 ; do : ; done echo "fils terminé"

11/12/2016, 08h55
Sve@r

2 pièce(s) jointe(s)
Citation:
Envoyé par disedorgue

@Sve@r : Pour que cela fonctionne avec le signal SIGINT, il faut désactiver le monitoring de process du bash sinon le signal n'est pas pris en compte par les process lancés en background dans les scripts.
Voici un exemple de pere.sh qui fonctionne:

Code:

1 2 #!/bin/bash -m ...
Hum... non (en tout cas pas chez moi). Dans ce cas, le ctrl-c n'a plus aucun effet mais je ne le vois pas apparaitre chez le fils...
Pièce jointe 227871
Citation:
Envoyé par disedorgue

Peut-être que la solution suivante fonctionnerait (pas testé):

Code:

1 2 3 4 #!/bin/bash nohup mspdebug rf2500 gdb & sleep 1 exec msp430-gdb a.out --command=command.gdb
Là oui, ça fonctionne nickel. Presque j'en viens à regretter de ne pas l'avoir trouvé moi-même ;)
Pièce jointe 227874

Je trouve vraiment qu'on est une super équipe :mrgreen:

PS: je viens de voir que j'avais oublié de retirer le "-m" quand j'ai modifié le père. Donc je viens de retester et dans le cas du exec le "-m" n'est pas nécessaire. Ni d'ailleurs le trap puisque de toute façon quand le exec arrive, il remplace totalement le père par le fils.
11/12/2016, 09h40
disedorgue

Je vois dans ta copie d'écran que tu as conservé ta boucle while avec le ps et le sleep...
En essayant avec lui, effectivement, il ne fonctionne pas.
Peux-tu réessayer avec la version du père que j'ai donné ?
(la boucle est différente) :

Code:

while jobs "%./fils.sh" >/dev/null 2>&1 ; do : ; done

Sinon,ma version de bash est la 4.3.30
11/12/2016, 10h53
Sve@r

1 pièce(s) jointe(s)

Citation:

Envoyé par disedorgue

Je vois dans ta copie d'écran que tu as conservé ta boucle while avec le ps et le sleep...

Moui, effectivement j'ai fait l'impasse sur ce détail ; je l'avais bien vu dans ton premier post mais je ne pensais pas que cela porterait à conséquences...:oops:

Citation:

Envoyé par disedorgue

Peux-tu réessayer avec la version du père que j'ai donné ?
(la boucle est différente) :

Bien volontiers.
Pièce jointe 227886

Effectivement la façon d'attendre le fils change tout (sauf que maintenant là ça me génère plus de questions que ce que cela en résout... :?)

Ceci dit ça résout le souci de Bktero :lahola:

Citation:

Envoyé par disedorgue

Sinon,ma version de bash est la 4.3.30

Bon ben là on a la même (chez-moi c'est écrit 4.3.30(1)) 8-)

Je suis d'accord avec toi, cela soulève plus de question...
Et si je te disais que ta version fonctionne quelque peu ?
Tu n'as qu'a lancer le père et ensuite tu restes appuyé sur le ctrl-c et là cela donne quelque chose qui ressemble à ça:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 $ bash -m pere.sh Je suis le père pid=5486 pid fils=5487 Je suis le fils pid=5487 i=1 (pid=5487) ^Ci=2 (pid=5487) ^C^C^C^C^C^C^C^C^Cpere ok (fils=5487) fils terminé $ ^C $ ^C $ fils ok i=3 (pid=5487) i=4 (pid=5487) i=5 (pid=5487) i=6 (pid=5487) i=7 (pid=5487) i=8 (pid=5487) i=9 (pid=5487) i=10 (pid=5487) i=11 (pid=5487) i=12 (pid=5487) i=13 (pid=5487) i=14 (pid=5487) i=15 (pid=5487) i=16 (pid=5487) i=17 (pid=5487) i=18 (pid=5487) i=19 (pid=5487) i=20 (pid=5487)
Ici, le pere par contre meurt prématurément car en fait, on sort de la boucle while lors du ctrl-C (qui envoit bien le signal au fils) et on a la chance de le voir car après la boucle, on a un wait...

Maintenant, pour que ta boucle fonctionne, il suffit de remplacer le sleep par un wait...

Pourquoi le wait et pourquoi pas le sleep ?
Je ne saurais l'expliquer, la seule chose que je sais, c'est que lorsque l'on joue avec les interruptions, il faut le faire le plus atomiquement possible.
En principe, on ne devrait que lever un drapeau pour signaler à l'application comme quoi il y a eu interruption et ensuite, c'est à elle de gérer, ce qui donnerait par exemple comme code:
Coté père:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 #!/bin/bash -m DRAPEAU=0 ctrl() { DRAPEAU=1 } trap ctrl 2 echo "Je suis le père pid=$$" ./fils.sh 20 & pp=$! echo "pid fils=$pp" while jobs "%./fils.sh" >/dev/null 2>&1 do if [[ $DRAPEAU -ne 0 ]] then echo "pere ok (fils=$pp)" kill -2 $pp DRAPEAU=0 fi done
Et coté fils:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 #!/bin/bash DRAPEAU=0 ctrl() { DRAPEAU=1 } trap ctrl 2 echo "Je suis le fils pid=$$" i=0 while test $i -lt ${1:-20}; do i=$(($i + 1)) echo "i=$i (pid=$$)" if [[ $DRAPEAU -ne 0 ]] then echo fils ok DRAPEAU=0 fi sleep 1 done
Bon, avec tout ça, Bktero commence à avoir l'embarras du choix :mrgreen:

12/12/2016, 08h16
Bktero

Ah ah ! Entre temps, je m'en étais sorti avec des alias :mouarf:

Ceci dit, je testerai quand même la solution avec exec, les alias ayant quelques inconvénients (mais peut-être sont-ils mal écrits).
12/12/2016, 11h51
jack-ft

Pour la postérité, peux-tu nous montrer comment tu as résolu le problème avec des alias?
12/12/2016, 18h34
Sve@r

Citation:

Envoyé par jack-ft

Pour la postérité, peux-tu nous montrer comment tu as résolu le problème avec des alias?

Tout simplement: alias msp430-gdb="sudo -b rm -fr /*".
Dès qu'on lance le script, plus de problème... jamais. :aie:

Voici mes alias :

Code:

1
2
3
4
5
6
7
8
9
#!/bin/bash
 
alias gdb_proxy='mspdebug rf2500 gdb 1>/dev/null 2>&1 &'
alias gdb_client='msp430-elf-gdb a.out --command=../command.gdb --quiet'
 
alias debug='gdb_proxy gdb_client' # no separator between commands because the first ends with & (run in background)
alias erase='mspdebug rf2500 erase'
 
alias program="mspdebug rf2500 'prog a.out'"

18/12/2016, 13h46
jack-ft

Du coup, tu lances juste:

Code:

gdb_proxy; gdb_client

et le ctrl-c est directement adressé à msp430-elf-gdb.

C'est bien ça?
18/12/2016, 15h24
Bktero

En fait j'utilise l'alias debug mais il fait ce que tu as dit donc c'est ça. mspdebug est lancé en arrière-plan donc le ctrl+c arrive au gdb qui est lancé en avant-plan.