J'ai créé une règle udev qui au branchement d'une montre garmin lance un
script
Ce script lance une application (graphique) permettant la gestion des
courses sur ce type de montre.
La règle fonctionne a peu pret bien.
Je m'explique
Normalement à l'insertion d'un périphérique usb celui-ci est vmonté
automatiquement sans que je m'occupe de quoi que ce soit.
Dans mon cas de figure ça ne fonctionne pas vraiment lors du branchement
de la montre la règle est bien exécutée, l'application se lance mais je
dois attendre un gros moment avant que la montre soit montée.
Ce qui n'est pas le cas si j'enlève la règle
La règle :
SUBSYSTEM=="usb", ATTR{idVendor}=="091e",
ATTR{idProduct}=="25ca",RUN+="/bin/su pascal -c
'/home/pascal/Desktop/udev-turtlesport.sh'"
le script
#!/bin/bash
export DISPLAY=":0.0"
/usr/bin/turtlesport &
Une idée pour faire en sorte que ma règle soit exécutée après le montage ?
# On veut que le script rende la main tout de suite. { c=0
# On attend que le périphérique soit monté. while ! mountpoint -q /media/GARMIN ; do sleep 0.5 c=$((c+1)) # Au bout d'un certain temps on abandonne. if [ "$c" = 20 ]; then exit 1 fi done
export DISPLAY=":0.0" /usr/bin/turtlesport&
}& ----------------------------------------------
Fais une tentative directement en ligne de commandes 1) alors que la clé n'est pas montée et 2) quand la clé est montée.
lorsque la clé est montée: https://www.dropbox.com/s/lbng8mu9bgh7dw5/mont%C3%A9e.png Lorsque la clé n'est pas montée https://www.dropbox.com/s/jfa5mx5hcpknkxt/non-mont%C3%A9e.png
Tu n'as pas exécuté exactement le même script que celui que je t'avais proposé (celui avec l'option -q pour mountpoint).
Mais bon, c'est pas grave, manifestement le script rend bien la main, c'est juste que ta console est polluée par des messages.
Exécute celui-là (vraiment celui-là hein, pas un autre qui ressemble) en ligne de commandes :
# On veut que le script rende la main tout de suite. { c=0
# On attend que le périphérique soit monté. while ! mountpoint -q /media/GARMIN ; do sleep 0.5 c=$((c+1)) # Au bout d'un certain temps on abandonne. if [ "$c" = 20 ]; then exit 1 fi done
On est d'accord que ça te rend bien la main instantanément, que la clé soit montée ou non, n'est-ce pas ?
Si on est d'accord, alors teste-le dans ta règle udev. Et si ça ne mache toujours pas, alors c'est qu'il y a une « siouxerie » au niveau de udev qui m'échappe totalement (ce qui est tout à fait possible, voire très probable).
-- François Lafont
Le 09/12/2012 20:15, Pascal a écrit :
Essaye le script ci-dessous (c'est le même sauf que j'ai ajouté l'option
-q qui rend la commande mountpoint silencieuse) :
# On veut que le script rende la main tout de suite.
{
c=0
# On attend que le périphérique soit monté.
while ! mountpoint -q /media/GARMIN ; do
sleep 0.5
c=$((c+1))
# Au bout d'un certain temps on abandonne.
if [ "$c" = 20 ]; then
exit 1
fi
done
export DISPLAY=":0.0"
/usr/bin/turtlesport&
}&
----------------------------------------------
Fais une tentative directement en ligne de commandes 1) alors que la clé
n'est pas montée et 2) quand la clé est montée.
lorsque la clé est montée:
https://www.dropbox.com/s/lbng8mu9bgh7dw5/mont%C3%A9e.png
Lorsque la clé n'est pas montée
https://www.dropbox.com/s/jfa5mx5hcpknkxt/non-mont%C3%A9e.png
Tu n'as pas exécuté exactement le même script que celui que je t'avais
proposé (celui avec l'option -q pour mountpoint).
Mais bon, c'est pas grave, manifestement le script rend bien la main,
c'est juste que ta console est polluée par des messages.
Exécute celui-là (vraiment celui-là hein, pas un autre qui ressemble) en
ligne de commandes :
# On veut que le script rende la main tout de suite.
{
c=0
# On attend que le périphérique soit monté.
while ! mountpoint -q /media/GARMIN ; do
sleep 0.5
c=$((c+1))
# Au bout d'un certain temps on abandonne.
if [ "$c" = 20 ]; then
exit 1
fi
done
On est d'accord que ça te rend bien la main instantanément, que la clé
soit montée ou non, n'est-ce pas ?
Si on est d'accord, alors teste-le dans ta règle udev. Et si ça ne mache
toujours pas, alors c'est qu'il y a une « siouxerie » au niveau de udev
qui m'échappe totalement (ce qui est tout à fait possible, voire très
probable).
# On veut que le script rende la main tout de suite. { c=0
# On attend que le périphérique soit monté. while ! mountpoint -q /media/GARMIN ; do sleep 0.5 c=$((c+1)) # Au bout d'un certain temps on abandonne. if [ "$c" = 20 ]; then exit 1 fi done
export DISPLAY=":0.0" /usr/bin/turtlesport&
}& ----------------------------------------------
Fais une tentative directement en ligne de commandes 1) alors que la clé n'est pas montée et 2) quand la clé est montée.
lorsque la clé est montée: https://www.dropbox.com/s/lbng8mu9bgh7dw5/mont%C3%A9e.png Lorsque la clé n'est pas montée https://www.dropbox.com/s/jfa5mx5hcpknkxt/non-mont%C3%A9e.png
Tu n'as pas exécuté exactement le même script que celui que je t'avais proposé (celui avec l'option -q pour mountpoint).
Mais bon, c'est pas grave, manifestement le script rend bien la main, c'est juste que ta console est polluée par des messages.
Exécute celui-là (vraiment celui-là hein, pas un autre qui ressemble) en ligne de commandes :
# On veut que le script rende la main tout de suite. { c=0
# On attend que le périphérique soit monté. while ! mountpoint -q /media/GARMIN ; do sleep 0.5 c=$((c+1)) # Au bout d'un certain temps on abandonne. if [ "$c" = 20 ]; then exit 1 fi done
On est d'accord que ça te rend bien la main instantanément, que la clé soit montée ou non, n'est-ce pas ?
Si on est d'accord, alors teste-le dans ta règle udev. Et si ça ne mache toujours pas, alors c'est qu'il y a une « siouxerie » au niveau de udev qui m'échappe totalement (ce qui est tout à fait possible, voire très probable).
-- François Lafont
Pascal
Le 09/12/2012 20:38, Francois Lafont a écrit :
#!/bin/bash
# On veut que le script rende la main tout de suite. { c=0
# On attend que le périphérique soit monté. while ! mountpoint -q /media/GARMIN ; do sleep 0.5 c=$((c+1)) # Au bout d'un certain temps on abandonne. if [ "$c" = 20 ]; then exit 1 fi done
export DISPLAY=":0.0" /usr/bin/turtlesport&
}>/dev/null 2>&1&
Roulement de tambour ......................................... ..............................................................
ça marche !!!!
je pense que le ">/dev/null 2>&1&" y est pour beaucoup, d'ailleurs si j'enlève le -q ça marche toujours
Le script sans ">/dev/null 2>&1&" ne me rendait pas vraiment la main il fallait que j'appuie sur la touche entrée
D'ailleurs, ce script marche aussi du coup : #!/bin/bash
# On veut que le script rende la main tout de suite. { export DISPLAY=":0.0" /usr/bin/turtlesport &
} >/dev/null 2>&1 &
Merci beaucoup pour ton aide
Le 09/12/2012 20:38, Francois Lafont a écrit :
#!/bin/bash
# On veut que le script rende la main tout de suite.
{
c=0
# On attend que le périphérique soit monté.
while ! mountpoint -q /media/GARMIN ; do
sleep 0.5
c=$((c+1))
# Au bout d'un certain temps on abandonne.
if [ "$c" = 20 ]; then
exit 1
fi
done
export DISPLAY=":0.0"
/usr/bin/turtlesport&
}>/dev/null 2>&1&
Roulement de tambour .........................................
..............................................................
ça marche !!!!
je pense que le ">/dev/null 2>&1&" y est pour beaucoup, d'ailleurs si
j'enlève le -q ça marche toujours
Le script sans ">/dev/null 2>&1&" ne me rendait pas vraiment la main il
fallait que j'appuie sur la touche entrée
D'ailleurs, ce script marche aussi du coup :
#!/bin/bash
# On veut que le script rende la main tout de suite.
{
export DISPLAY=":0.0"
/usr/bin/turtlesport &
# On veut que le script rende la main tout de suite. { c=0
# On attend que le périphérique soit monté. while ! mountpoint -q /media/GARMIN ; do sleep 0.5 c=$((c+1)) # Au bout d'un certain temps on abandonne. if [ "$c" = 20 ]; then exit 1 fi done
export DISPLAY=":0.0" /usr/bin/turtlesport&
}>/dev/null 2>&1&
Roulement de tambour ......................................... ..............................................................
ça marche !!!!
je pense que le ">/dev/null 2>&1&" y est pour beaucoup, d'ailleurs si j'enlève le -q ça marche toujours
Le script sans ">/dev/null 2>&1&" ne me rendait pas vraiment la main il fallait que j'appuie sur la touche entrée
D'ailleurs, ce script marche aussi du coup : #!/bin/bash
# On veut que le script rende la main tout de suite. { export DISPLAY=":0.0" /usr/bin/turtlesport &
} >/dev/null 2>&1 &
Merci beaucoup pour ton aide
Francois Lafont
Le 10/12/2012 17:26, Pascal a écrit :
Roulement de tambour ......................................... ..............................................................
ça marche !!!!
Ben mince alors. Je crois que udev (enfin ton udev sur ton système) nous a fait un tour de cochon.
je pense que le ">/dev/null 2>&1&" y est pour beaucoup, d'ailleurs si j'enlève le -q ça marche toujours
Ça c'est normal. Effectivement, le -q ne sert plus à grand chose avec «
/dev/null 2>&1 » puisque stdout et stderr ont été redirigées vers
/dev/null.
Le script sans ">/dev/null 2>&1&" ne me rendait pas vraiment la main
Si, si, il te rendait *vraiment* la main sauf que des messages en sortie venaient polluer ta console et te donnaient la (fausse) impression que tu n'avais pas la main.
D'ailleurs, ce script marche aussi du coup : #!/bin/bash
# On veut que le script rende la main tout de suite. { export DISPLAY=":0.0" /usr/bin/turtlesport &
} >/dev/null 2>&1 &
Sans doute mais dans ce cas, turtlesport se lancera avant même que la clé ne soit montée, ce qui n'était pas la consigne de départ il me semble. Mais bon, du moment que ça te convient.
Merci beaucoup pour ton aide
Pas de quoi.
Maintenant, je suis perplexe l'explication de ce phénomène. Une explication (peut-être un peu foireuse) serait de dire que udev (enfin sur le système de Pascal) ne voulait pas passer à la suite tant que le script renvoyait du texte en sortie (sur stdout et/ou stderr) en dépit de la présence du « & ». Mais dès qu'on l'a rendu « muet » (en redirigeant tout vers /dev/null). Ça vous parait plausible comme explication ?
Sur ma Squeeze en tout cas, quand je fais une règle udev dans le même style, que le script écrive des choses en sortie ou non, je n'ai pas cette différence de comportement...
-- François Lafont
Le 10/12/2012 17:26, Pascal a écrit :
Roulement de tambour .........................................
..............................................................
ça marche !!!!
Ben mince alors. Je crois que udev (enfin ton udev sur ton système) nous
a fait un tour de cochon.
je pense que le ">/dev/null 2>&1&" y est pour beaucoup, d'ailleurs si
j'enlève le -q ça marche toujours
Ça c'est normal. Effectivement, le -q ne sert plus à grand chose avec «
/dev/null 2>&1 » puisque stdout et stderr ont été redirigées vers
/dev/null.
Le script sans ">/dev/null 2>&1&" ne me rendait pas vraiment la main
Si, si, il te rendait *vraiment* la main sauf que des messages en sortie
venaient polluer ta console et te donnaient la (fausse) impression que
tu n'avais pas la main.
D'ailleurs, ce script marche aussi du coup :
#!/bin/bash
# On veut que le script rende la main tout de suite.
{
export DISPLAY=":0.0"
/usr/bin/turtlesport &
} >/dev/null 2>&1 &
Sans doute mais dans ce cas, turtlesport se lancera avant même que la
clé ne soit montée, ce qui n'était pas la consigne de départ il me
semble. Mais bon, du moment que ça te convient.
Merci beaucoup pour ton aide
Pas de quoi.
Maintenant, je suis perplexe l'explication de ce phénomène. Une
explication (peut-être un peu foireuse) serait de dire que udev (enfin
sur le système de Pascal) ne voulait pas passer à la suite tant que le
script renvoyait du texte en sortie (sur stdout et/ou stderr) en dépit
de la présence du « & ». Mais dès qu'on l'a rendu « muet » (en
redirigeant tout vers /dev/null). Ça vous parait plausible comme
explication ?
Sur ma Squeeze en tout cas, quand je fais une règle udev dans le même
style, que le script écrive des choses en sortie ou non, je n'ai pas
cette différence de comportement...
Roulement de tambour ......................................... ..............................................................
ça marche !!!!
Ben mince alors. Je crois que udev (enfin ton udev sur ton système) nous a fait un tour de cochon.
je pense que le ">/dev/null 2>&1&" y est pour beaucoup, d'ailleurs si j'enlève le -q ça marche toujours
Ça c'est normal. Effectivement, le -q ne sert plus à grand chose avec «
/dev/null 2>&1 » puisque stdout et stderr ont été redirigées vers
/dev/null.
Le script sans ">/dev/null 2>&1&" ne me rendait pas vraiment la main
Si, si, il te rendait *vraiment* la main sauf que des messages en sortie venaient polluer ta console et te donnaient la (fausse) impression que tu n'avais pas la main.
D'ailleurs, ce script marche aussi du coup : #!/bin/bash
# On veut que le script rende la main tout de suite. { export DISPLAY=":0.0" /usr/bin/turtlesport &
} >/dev/null 2>&1 &
Sans doute mais dans ce cas, turtlesport se lancera avant même que la clé ne soit montée, ce qui n'était pas la consigne de départ il me semble. Mais bon, du moment que ça te convient.
Merci beaucoup pour ton aide
Pas de quoi.
Maintenant, je suis perplexe l'explication de ce phénomène. Une explication (peut-être un peu foireuse) serait de dire que udev (enfin sur le système de Pascal) ne voulait pas passer à la suite tant que le script renvoyait du texte en sortie (sur stdout et/ou stderr) en dépit de la présence du « & ». Mais dès qu'on l'a rendu « muet » (en redirigeant tout vers /dev/null). Ça vous parait plausible comme explication ?
Sur ma Squeeze en tout cas, quand je fais une règle udev dans le même style, que le script écrive des choses en sortie ou non, je n'ai pas cette différence de comportement...
-- François Lafont
Pascal
Le script sans ">/dev/null 2>&1&" ne me rendait pas vraiment la main
Si, si, il te rendait *vraiment* la main sauf que des messages en sortie venaient polluer ta console et te donnaient la (fausse) impression que tu n'avais pas la main.
Mais comment vois tu qu'il me rend la main ?
D'ailleurs, ce script marche aussi du coup : #!/bin/bash
# On veut que le script rende la main tout de suite. { export DISPLAY=":0.0" /usr/bin/turtlesport&
}>/dev/null 2>&1&
Sans doute mais dans ce cas, turtlesport se lancera avant même que la clé ne soit montée, ce qui n'était pas la consigne de départ il me semble. Mais bon, du moment que ça te convient.
Effectivement le disque est monté un tout petit peu après mais vraiment rien d'handicapant, c'est quasiment immédiat
Merci beaucoup pour ton aide
Pas de quoi.
Sisi !! ;-)
Maintenant, je suis perplexe l'explication de ce phénomène. Une explication (peut-être un peu foireuse) serait de dire que udev (enfin sur le système de Pascal) ne voulait pas passer à la suite tant que le script renvoyait du texte en sortie (sur stdout et/ou stderr) en dépit de la présence du «& ». Mais dès qu'on l'a rendu « muet » (en redirigeant tout vers /dev/null). Ça vous parait plausible comme explication ?
Moi je trouve ça plausible !! ;-)
Merci encore
Le script sans ">/dev/null 2>&1&" ne me rendait pas vraiment la main
Si, si, il te rendait *vraiment* la main sauf que des messages en sortie
venaient polluer ta console et te donnaient la (fausse) impression que
tu n'avais pas la main.
Mais comment vois tu qu'il me rend la main ?
D'ailleurs, ce script marche aussi du coup :
#!/bin/bash
# On veut que le script rende la main tout de suite.
{
export DISPLAY=":0.0"
/usr/bin/turtlesport&
}>/dev/null 2>&1&
Sans doute mais dans ce cas, turtlesport se lancera avant même que la
clé ne soit montée, ce qui n'était pas la consigne de départ il me
semble. Mais bon, du moment que ça te convient.
Effectivement le disque est monté un tout petit peu après mais vraiment
rien d'handicapant, c'est quasiment immédiat
Merci beaucoup pour ton aide
Pas de quoi.
Sisi !! ;-)
Maintenant, je suis perplexe l'explication de ce phénomène. Une
explication (peut-être un peu foireuse) serait de dire que udev (enfin
sur le système de Pascal) ne voulait pas passer à la suite tant que le
script renvoyait du texte en sortie (sur stdout et/ou stderr) en dépit
de la présence du «& ». Mais dès qu'on l'a rendu « muet » (en
redirigeant tout vers /dev/null). Ça vous parait plausible comme
explication ?
Le script sans ">/dev/null 2>&1&" ne me rendait pas vraiment la main
Si, si, il te rendait *vraiment* la main sauf que des messages en sortie venaient polluer ta console et te donnaient la (fausse) impression que tu n'avais pas la main.
Mais comment vois tu qu'il me rend la main ?
D'ailleurs, ce script marche aussi du coup : #!/bin/bash
# On veut que le script rende la main tout de suite. { export DISPLAY=":0.0" /usr/bin/turtlesport&
}>/dev/null 2>&1&
Sans doute mais dans ce cas, turtlesport se lancera avant même que la clé ne soit montée, ce qui n'était pas la consigne de départ il me semble. Mais bon, du moment que ça te convient.
Effectivement le disque est monté un tout petit peu après mais vraiment rien d'handicapant, c'est quasiment immédiat
Merci beaucoup pour ton aide
Pas de quoi.
Sisi !! ;-)
Maintenant, je suis perplexe l'explication de ce phénomène. Une explication (peut-être un peu foireuse) serait de dire que udev (enfin sur le système de Pascal) ne voulait pas passer à la suite tant que le script renvoyait du texte en sortie (sur stdout et/ou stderr) en dépit de la présence du «& ». Mais dès qu'on l'a rendu « muet » (en redirigeant tout vers /dev/null). Ça vous parait plausible comme explication ?
Moi je trouve ça plausible !! ;-)
Merci encore
Francois Lafont
Le 10/12/2012 18:16, Pascal a écrit :
Si, si, il te rendait *vraiment* la main sauf que des messages en sortie venaient polluer ta console et te donnaient la (fausse) impression que tu n'avais pas la main.
Que voit-on ? Un saut de ligne puis... le prompt (:~$). Donc tu as la main.
Alors certes tu as plein de choses qui s'affichent ensuite et qui polluent la console mais en vérité tu as déjà la main à ce moment là car il y a le prompt. L'affichage de messages vient parasiter ton terminal mais à ce moment là tu peux bien lancer ce que tu veux (un ls par exemple même si encore une fois ta saisie et le résultat de la commande seront pollués par les messages qui s'affichent).
Si le script ne t'avait pas rendu la main immédiatement, tu aurais eu aussi tous ces messages mais il n'y aurait pas eu de prompt juste après le lancement de Desktop/udev-turtlesport.sh.
Maintenant, je suis perplexe l'explication de ce phénomène. Une explication (peut-être un peu foireuse) serait de dire que udev (enfin sur le système de Pascal) ne voulait pas passer à la suite tant que le script renvoyait du texte en sortie (sur stdout et/ou stderr) en dépit de la présence du «& ». Mais dès qu'on l'a rendu « muet » (en redirigeant tout vers /dev/null). Ça vous parait plausible comme explication ?
Moi je trouve ça plausible !! ;-)
Déjà, nous ne voyons pas d'autres explications... ;-)
-- François Lafont
Le 10/12/2012 18:16, Pascal a écrit :
Si, si, il te rendait *vraiment* la main sauf que des messages en sortie
venaient polluer ta console et te donnaient la (fausse) impression que
tu n'avais pas la main.
Que voit-on ? Un saut de ligne puis... le prompt (pascal@Maison:~$).
Donc tu as la main.
Alors certes tu as plein de choses qui s'affichent ensuite et qui
polluent la console mais en vérité tu as déjà la main à ce moment là car
il y a le prompt. L'affichage de messages vient parasiter ton terminal
mais à ce moment là tu peux bien lancer ce que tu veux (un ls par
exemple même si encore une fois ta saisie et le résultat de la commande
seront pollués par les messages qui s'affichent).
Si le script ne t'avait pas rendu la main immédiatement, tu aurais eu
aussi tous ces messages mais il n'y aurait pas eu de prompt juste après
le lancement de Desktop/udev-turtlesport.sh.
Maintenant, je suis perplexe l'explication de ce phénomène. Une
explication (peut-être un peu foireuse) serait de dire que udev (enfin
sur le système de Pascal) ne voulait pas passer à la suite tant que le
script renvoyait du texte en sortie (sur stdout et/ou stderr) en dépit
de la présence du «& ». Mais dès qu'on l'a rendu « muet » (en
redirigeant tout vers /dev/null). Ça vous parait plausible comme
explication ?
Moi je trouve ça plausible !! ;-)
Déjà, nous ne voyons pas d'autres explications... ;-)
Si, si, il te rendait *vraiment* la main sauf que des messages en sortie venaient polluer ta console et te donnaient la (fausse) impression que tu n'avais pas la main.
Que voit-on ? Un saut de ligne puis... le prompt (:~$). Donc tu as la main.
Alors certes tu as plein de choses qui s'affichent ensuite et qui polluent la console mais en vérité tu as déjà la main à ce moment là car il y a le prompt. L'affichage de messages vient parasiter ton terminal mais à ce moment là tu peux bien lancer ce que tu veux (un ls par exemple même si encore une fois ta saisie et le résultat de la commande seront pollués par les messages qui s'affichent).
Si le script ne t'avait pas rendu la main immédiatement, tu aurais eu aussi tous ces messages mais il n'y aurait pas eu de prompt juste après le lancement de Desktop/udev-turtlesport.sh.
Maintenant, je suis perplexe l'explication de ce phénomène. Une explication (peut-être un peu foireuse) serait de dire que udev (enfin sur le système de Pascal) ne voulait pas passer à la suite tant que le script renvoyait du texte en sortie (sur stdout et/ou stderr) en dépit de la présence du «& ». Mais dès qu'on l'a rendu « muet » (en redirigeant tout vers /dev/null). Ça vous parait plausible comme explication ?
Moi je trouve ça plausible !! ;-)
Déjà, nous ne voyons pas d'autres explications... ;-)
