Bon, j'ai déjà eu du mal à trouver un titre. Ça doit bien démontrer que
ce n'est pas clair dans ma tête. Pourtant l'exemple est assez simple est
parlant.
Depuis peu (sans doute après des mises à jour), j'ai un comportement qui
a légèrement changé.
J'ai un script1 (en bash) sur ma machine (gentoo), qui lance une
commande :
---------------------------- %< ------------------------------
ssh -x $DISTUSER@$HOST script_distant
---------------------------- %< ------------------------------
Jusqu'à ces derniers jours, l'ensemble me rendait la main juste après
l'affichage du echo, sans plus attendre.
Depuis, l'ensemble ne me rend la main qu'après le timeout de la commande
xcowsay (ligne 4), soit 60 secondes après.
Pourtant, la ligne 4: rend bien la main aussitôt, je l'ai vérifié. Si je
lance directement script_distant sur la machine distante, le script me
rend la main aussitôt. C'est quand je le lance par ssh que le
comportement change. Le script ne se termine pas tant que xcowsay est
affiché. Et ça, c'est nouveau.
Je ne souhaite pas mettre & à l'appel :
---------------------------- %< ------------------------------
ssh -x $DISTUSER@$HOST script_distant &
---------------------------- %< ------------------------------
parce que du coup, ça me rend la main immédiatement, avant même
l'affichage du echo (ici, je simplifie l'exemple, ça va plus loin qu'un
simple echo).
J'espère avoir été clair, mais j'en doute quand même un peu :)
Si vous avez un idée, une explication, ou mieux une solution, je vous en
remercie d'avance.
Le Wed, 21 Dec 2016 05:03:32 +0000, Christophe PEREZ a écrit :
Pourtant l'exemple est assez simple est parlant.
Trop, puisqu'en fait aussi simplifié, ça fonctionne. Il faut donc que je trouve ce qui différencie cet exemple de mon cas réel en l'empêchant d'avoir le même comportement.
Le Wed, 21 Dec 2016 05:03:32 +0000, Christophe PEREZ a écrit :
Pourtant l'exemple est assez simple est parlant.
Trop, puisqu'en fait aussi simplifié, ça fonctionne.
Il faut donc que je trouve ce qui différencie cet exemple de mon cas réel
en l'empêchant d'avoir le même comportement.
Le Wed, 21 Dec 2016 05:03:32 +0000, Christophe PEREZ a écrit :
Pourtant l'exemple est assez simple est parlant.
Trop, puisqu'en fait aussi simplifié, ça fonctionne. Il faut donc que je trouve ce qui différencie cet exemple de mon cas réel en l'empêchant d'avoir le même comportement.
Christophe PEREZ
Le Wed, 21 Dec 2016 05:33:54 +0000, Christophe PEREZ a écrit :
Il faut donc que je trouve ce qui différencie cet exemple de mon cas réel
En fait, ça n'a aucun rapport avec tout ce que j'ai imaginé. Mon script_distant fait appel à un autre script, contenant : ---------------------------- %< ------------------------------ sleep 60 && xset dpms 240 300 480 && xset +dpms & ---------------------------- %< ------------------------------ Et c'est CE timeout de 60sec qui retarde la fermeture de la session ssh. Mais c'est le seul moyen que j'ai trouvé pour retarder l'exécution de mes commandes xset. En effet, ce script se charge d'activer/désactiver le PowerManagement (qdbus org.freedesktop.PowerManagement.Inhibit /org/freedesktop/ PowerManagement/Inhibit Inhibit) afin de désactiver la mise en veille automatique, mais je me suis rendu compte que l'action n'est pas immédiate, cela prend plusieurs secondes tout en rendant la main, et ça me désactive aussi le dpms bien après que mon script soit terminé. L'exemple s'illustre bien avec pour script_distant : ---------------------------- %< ------------------------------ echo "debut script distant" sleep 10 && echo sleep & echo "fin script distant" ---------------------------- %< ------------------------------ J'ai essayé plusieurs choses avec des nohup et autres, mais sans meilleur résultat.
Le Wed, 21 Dec 2016 05:33:54 +0000, Christophe PEREZ a écrit :
Il faut donc que je trouve ce qui différencie cet exemple de mon cas
réel
En fait, ça n'a aucun rapport avec tout ce que j'ai imaginé.
Mon script_distant fait appel à un autre script, contenant :
---------------------------- %< ------------------------------
sleep 60 && xset dpms 240 300 480 && xset +dpms &
---------------------------- %< ------------------------------
Et c'est CE timeout de 60sec qui retarde la fermeture de la session ssh.
Mais c'est le seul moyen que j'ai trouvé pour retarder l'exécution de mes
commandes xset.
En effet, ce script se charge d'activer/désactiver le PowerManagement
(qdbus org.freedesktop.PowerManagement.Inhibit /org/freedesktop/
PowerManagement/Inhibit Inhibit) afin de désactiver la mise en veille
automatique, mais je me suis rendu compte que l'action n'est pas
immédiate, cela prend plusieurs secondes tout en rendant la main, et ça
me désactive aussi le dpms bien après que mon script soit terminé.
L'exemple s'illustre bien avec pour script_distant :
---------------------------- %< ------------------------------
echo "debut script distant"
sleep 10 && echo sleep &
echo "fin script distant"
---------------------------- %< ------------------------------
J'ai essayé plusieurs choses avec des nohup et autres, mais sans meilleur
résultat.
Le Wed, 21 Dec 2016 05:33:54 +0000, Christophe PEREZ a écrit :
Il faut donc que je trouve ce qui différencie cet exemple de mon cas réel
En fait, ça n'a aucun rapport avec tout ce que j'ai imaginé. Mon script_distant fait appel à un autre script, contenant : ---------------------------- %< ------------------------------ sleep 60 && xset dpms 240 300 480 && xset +dpms & ---------------------------- %< ------------------------------ Et c'est CE timeout de 60sec qui retarde la fermeture de la session ssh. Mais c'est le seul moyen que j'ai trouvé pour retarder l'exécution de mes commandes xset. En effet, ce script se charge d'activer/désactiver le PowerManagement (qdbus org.freedesktop.PowerManagement.Inhibit /org/freedesktop/ PowerManagement/Inhibit Inhibit) afin de désactiver la mise en veille automatique, mais je me suis rendu compte que l'action n'est pas immédiate, cela prend plusieurs secondes tout en rendant la main, et ça me désactive aussi le dpms bien après que mon script soit terminé. L'exemple s'illustre bien avec pour script_distant : ---------------------------- %< ------------------------------ echo "debut script distant" sleep 10 && echo sleep & echo "fin script distant" ---------------------------- %< ------------------------------ J'ai essayé plusieurs choses avec des nohup et autres, mais sans meilleur résultat.
Jo Engo
Le Wed, 21 Dec 2016 06:07:02 +0000, Christophe PEREZ a écrit :
---------------------------- %< ------------------------------ sleep 60 && xset dpms 240 300 480 && xset +dpms & ---------------------------- %< ------------------------------ Et c'est CE timeout de 60sec qui retarde la fermeture de la session ssh.
Ce n'est que le dernier xset qui est concerné par l'&. -- Tout est signe pour celui qui sait voir. -+- Le Coran -+-
Le Wed, 21 Dec 2016 06:07:02 +0000, Christophe PEREZ a écrit :
---------------------------- %< ------------------------------
sleep 60 && xset dpms 240 300 480 && xset +dpms &
---------------------------- %< ------------------------------
Et c'est CE timeout de 60sec qui retarde la fermeture de la session ssh.
Ce n'est que le dernier xset qui est concerné par l'&.
--
Tout est signe pour celui qui sait voir.
-+- Le Coran -+-
Le Wed, 21 Dec 2016 06:07:02 +0000, Christophe PEREZ a écrit :
---------------------------- %< ------------------------------ sleep 60 && xset dpms 240 300 480 && xset +dpms & ---------------------------- %< ------------------------------ Et c'est CE timeout de 60sec qui retarde la fermeture de la session ssh.
Ce n'est que le dernier xset qui est concerné par l'&. -- Tout est signe pour celui qui sait voir. -+- Le Coran -+-
Nicolas George
Christophe PEREZ , dans le message <o3d666$c2f$, a écrit :
sleep 60 && xset dpms 240 300 480 && xset +dpms &
Comme Jo le signale, & a priorité sur &&, donc le sleep est synchrone. Tu peux grouper les commandes avec { ... } et mettre le & après pour exécuter le groupe de manière asynchrone.
J'ai essayé plusieurs choses avec des nohup
NE PAS UTILISER NOHUP, NOHUP C'EST POURRI, ÇA N'AURAIT JAMAIS DÛ EXISTER.
et autres
En revanche, il y a d'autres points à surveiller. Certaines versions de SSH garder la connexion ouverte tant qu'ils voient un file descriptor ouvert, donc sois bien sûr d'avoir fermé stdin, stdout et stderr dès que possible. Certains versions de SSH ont aussi des trucs bizarres avec le terminal de contrôle, donc setsid peut aider.
Christophe PEREZ , dans le message <o3d666$c2f$1@serveur2.novazur.fr>, a
écrit :
sleep 60 && xset dpms 240 300 480 && xset +dpms &
Comme Jo le signale, & a priorité sur &&, donc le sleep est synchrone.
Tu peux grouper les commandes avec { ... } et mettre le & après pour
exécuter le groupe de manière asynchrone.
J'ai essayé plusieurs choses avec des nohup
NE PAS UTILISER NOHUP, NOHUP C'EST POURRI, ÇA N'AURAIT JAMAIS DÛ
EXISTER.
et autres
En revanche, il y a d'autres points à surveiller. Certaines versions de
SSH garder la connexion ouverte tant qu'ils voient un file descriptor
ouvert, donc sois bien sûr d'avoir fermé stdin, stdout et stderr dès que
possible.
Certains versions de SSH ont aussi des trucs bizarres avec le terminal
de contrôle, donc setsid peut aider.
Christophe PEREZ , dans le message <o3d666$c2f$, a écrit :
sleep 60 && xset dpms 240 300 480 && xset +dpms &
Comme Jo le signale, & a priorité sur &&, donc le sleep est synchrone. Tu peux grouper les commandes avec { ... } et mettre le & après pour exécuter le groupe de manière asynchrone.
J'ai essayé plusieurs choses avec des nohup
NE PAS UTILISER NOHUP, NOHUP C'EST POURRI, ÇA N'AURAIT JAMAIS DÛ EXISTER.
et autres
En revanche, il y a d'autres points à surveiller. Certaines versions de SSH garder la connexion ouverte tant qu'ils voient un file descriptor ouvert, donc sois bien sûr d'avoir fermé stdin, stdout et stderr dès que possible. Certains versions de SSH ont aussi des trucs bizarres avec le terminal de contrôle, donc setsid peut aider.
Christophe PEREZ
Le Wed, 21 Dec 2016 10:27:21 +0000, Nicolas George a écrit :
Comme Jo le signale, & a priorité sur &&
Ah, je l'apprends.
, donc le sleep est synchrone.
Cependant, à ce niveau, ça fait ce que je veux.
Tu peux grouper les commandes avec { ... } et mettre le & après pour exécuter le groupe de manière asynchrone.
Je testerai ça.
NE PAS UTILISER NOHUP, NOHUP C'EST POURRI, ÇA N'AURAIT JAMAIS DÛ EXISTER.
Ça tombe bien, je ne l'utilise jamais :) Mais dans mes recherches sur ce cas, je suis tombé sur tellement de proposition avec, que je pensais peut-être passer à côté de quelque chose.
En revanche, il y a d'autres points à surveiller. Certaines versions de SSH garder la connexion ouverte tant qu'ils voient un file descriptor ouvert, donc sois bien sûr d'avoir fermé stdin, stdout et stderr dès que possible.
Ah, je vais donc faire gaffe à ça.
Certains versions de SSH ont aussi des trucs bizarres avec le terminal de contrôle, donc setsid peut aider.
Je ne sais pas de quoi il s'agit, mais je vais y jeter un oeil. Merci.
Le Wed, 21 Dec 2016 10:27:21 +0000, Nicolas George a écrit :
Comme Jo le signale, & a priorité sur &&
Ah, je l'apprends.
, donc le sleep est synchrone.
Cependant, à ce niveau, ça fait ce que je veux.
Tu peux grouper les commandes avec { ... } et mettre le & après pour
exécuter le groupe de manière asynchrone.
Je testerai ça.
NE PAS UTILISER NOHUP, NOHUP C'EST POURRI, ÇA N'AURAIT JAMAIS DÛ
EXISTER.
Ça tombe bien, je ne l'utilise jamais :)
Mais dans mes recherches sur ce cas, je suis tombé sur tellement de
proposition avec, que je pensais peut-être passer à côté de quelque chose.
En revanche, il y a d'autres points à surveiller. Certaines versions de
SSH garder la connexion ouverte tant qu'ils voient un file descriptor
ouvert, donc sois bien sûr d'avoir fermé stdin, stdout et stderr dès que
possible.
Ah, je vais donc faire gaffe à ça.
Certains versions de SSH ont aussi des trucs bizarres avec le terminal
de contrôle, donc setsid peut aider.
Je ne sais pas de quoi il s'agit, mais je vais y jeter un oeil.
Merci.
Le Wed, 21 Dec 2016 10:27:21 +0000, Nicolas George a écrit :
Comme Jo le signale, & a priorité sur &&
Ah, je l'apprends.
, donc le sleep est synchrone.
Cependant, à ce niveau, ça fait ce que je veux.
Tu peux grouper les commandes avec { ... } et mettre le & après pour exécuter le groupe de manière asynchrone.
Je testerai ça.
NE PAS UTILISER NOHUP, NOHUP C'EST POURRI, ÇA N'AURAIT JAMAIS DÛ EXISTER.
Ça tombe bien, je ne l'utilise jamais :) Mais dans mes recherches sur ce cas, je suis tombé sur tellement de proposition avec, que je pensais peut-être passer à côté de quelque chose.
En revanche, il y a d'autres points à surveiller. Certaines versions de SSH garder la connexion ouverte tant qu'ils voient un file descriptor ouvert, donc sois bien sûr d'avoir fermé stdin, stdout et stderr dès que possible.
Ah, je vais donc faire gaffe à ça.
Certains versions de SSH ont aussi des trucs bizarres avec le terminal de contrôle, donc setsid peut aider.
Je ne sais pas de quoi il s'agit, mais je vais y jeter un oeil. Merci.
Christophe PEREZ
Le Wed, 21 Dec 2016 15:31:34 +0000, Christophe PEREZ a écrit :
Tu peux grouper les commandes avec { ... } et mettre le & après pour exécuter le groupe de manière asynchrone.
Je testerai ça.
Et bien c'était ça (enfin, à ceci près que j'ai du utiliser des parenthèses et non des accolades). Je suis pourtant persuadé d'avoir essayé, mais sans doute encore sur un mauvais exemple. Pour clarifier la solution adoptée, j'ai donc remplacé : ---------------------------- %< ------------------------------ sleep 60 && xset dpms 240 300 480 && xset +dpms & ---------------------------- %< ------------------------------ par : ---------------------------- %< ------------------------------ ( sleep 60 && xset dpms 240 300 480 && xset +dpms ) & ---------------------------- %< ------------------------------ Et le script rend bien la main, tout en différant l'exécution des commandes.
Le Wed, 21 Dec 2016 15:31:34 +0000, Christophe PEREZ a écrit :
Tu peux grouper les commandes avec { ... } et mettre le & après pour
exécuter le groupe de manière asynchrone.
Je testerai ça.
Et bien c'était ça (enfin, à ceci près que j'ai du utiliser des
parenthèses et non des accolades). Je suis pourtant persuadé d'avoir
essayé, mais sans doute encore sur un mauvais exemple.
Pour clarifier la solution adoptée, j'ai donc remplacé :
---------------------------- %< ------------------------------
sleep 60 && xset dpms 240 300 480 && xset +dpms &
---------------------------- %< ------------------------------
par :
---------------------------- %< ------------------------------
( sleep 60 && xset dpms 240 300 480 && xset +dpms ) &
---------------------------- %< ------------------------------
Et le script rend bien la main, tout en différant l'exécution des
commandes.
Le Wed, 21 Dec 2016 15:31:34 +0000, Christophe PEREZ a écrit :
Tu peux grouper les commandes avec { ... } et mettre le & après pour exécuter le groupe de manière asynchrone.
Je testerai ça.
Et bien c'était ça (enfin, à ceci près que j'ai du utiliser des parenthèses et non des accolades). Je suis pourtant persuadé d'avoir essayé, mais sans doute encore sur un mauvais exemple. Pour clarifier la solution adoptée, j'ai donc remplacé : ---------------------------- %< ------------------------------ sleep 60 && xset dpms 240 300 480 && xset +dpms & ---------------------------- %< ------------------------------ par : ---------------------------- %< ------------------------------ ( sleep 60 && xset dpms 240 300 480 && xset +dpms ) & ---------------------------- %< ------------------------------ Et le script rend bien la main, tout en différant l'exécution des commandes.
Damien Wyart
* Christophe PEREZ in fr.comp.os.linux.configuration:
Et bien c'était ça (enfin, à ceci près que j'ai du utiliser des parenthèses et non des accolades). Je suis pourtant persuadé d'avoir essayé, mais sans doute encore sur un mauvais exemple.
Pour les {}, il te manque peut-être juste un ; avant l'accolade fermante. C'est vraiment cosmétique, mais comme ça évite d'utiliser un sous-shell, c'est la solution la plus logique. Peux-tu juste nous dire si cela fonctionne ? Merci -- DW
* Christophe PEREZ <chris@novazur.fr> in fr.comp.os.linux.configuration:
Et bien c'était ça (enfin, à ceci près que j'ai du utiliser des
parenthèses et non des accolades). Je suis pourtant persuadé d'avoir
essayé, mais sans doute encore sur un mauvais exemple.
Pour les {}, il te manque peut-être juste un ; avant l'accolade
fermante. C'est vraiment cosmétique, mais comme ça évite d'utiliser un
sous-shell, c'est la solution la plus logique.
* Christophe PEREZ in fr.comp.os.linux.configuration:
Et bien c'était ça (enfin, à ceci près que j'ai du utiliser des parenthèses et non des accolades). Je suis pourtant persuadé d'avoir essayé, mais sans doute encore sur un mauvais exemple.
Pour les {}, il te manque peut-être juste un ; avant l'accolade fermante. C'est vraiment cosmétique, mais comme ça évite d'utiliser un sous-shell, c'est la solution la plus logique. Peux-tu juste nous dire si cela fonctionne ? Merci -- DW
Nicolas George
Damien Wyart , dans le message <585acc23$0$3359$, a écrit :
mais comme ça évite d'utiliser un sous-shell
C'est valable en général, mais ici, le & à la fin oblige à un sous-shell de toutes façons. On espère que le shell est assez intelligent pour ne pas en créer deux ; dash semble l'être.
Damien Wyart , dans le message <585acc23$0$3359$426a74cc@news.free.fr>,
a écrit :
mais comme ça évite d'utiliser un
sous-shell
C'est valable en général, mais ici, le & à la fin oblige à un sous-shell
de toutes façons. On espère que le shell est assez intelligent pour ne
pas en créer deux ; dash semble l'être.
Damien Wyart , dans le message <585acc23$0$3359$, a écrit :
mais comme ça évite d'utiliser un sous-shell
C'est valable en général, mais ici, le & à la fin oblige à un sous-shell de toutes façons. On espère que le shell est assez intelligent pour ne pas en créer deux ; dash semble l'être.
Christophe PEREZ
Le Wed, 21 Dec 2016 19:38:27 +0100, Damien Wyart a écrit :
Pour les {}, il te manque peut-être juste un ; avant l'accolade fermante.
Bien vu !
C'est vraiment cosmétique, mais comme ça évite d'utiliser un sous-shell, c'est la solution la plus logique.
Je préfère toujours faire au plus propre.
Peux-tu juste nous dire si cela fonctionne ?
C'est confirmé. Merci pour l'indice. J'avoue que l'erreur que j'avais ne me parlait pas beaucoup, mais j'aurais sans doute du trouver seul quand même.
Merci
Ben voyons :) Merci à toi.
Le Wed, 21 Dec 2016 19:38:27 +0100, Damien Wyart a écrit :
Pour les {}, il te manque peut-être juste un ; avant l'accolade
fermante.
Bien vu !
C'est vraiment cosmétique, mais comme ça évite d'utiliser un
sous-shell, c'est la solution la plus logique.
Je préfère toujours faire au plus propre.
Peux-tu juste nous dire si cela fonctionne ?
C'est confirmé. Merci pour l'indice. J'avoue que l'erreur que j'avais ne
me parlait pas beaucoup, mais j'aurais sans doute du trouver seul quand
même.
Le Wed, 21 Dec 2016 19:38:27 +0100, Damien Wyart a écrit :
Pour les {}, il te manque peut-être juste un ; avant l'accolade fermante.
Bien vu !
C'est vraiment cosmétique, mais comme ça évite d'utiliser un sous-shell, c'est la solution la plus logique.
Je préfère toujours faire au plus propre.
Peux-tu juste nous dire si cela fonctionne ?
C'est confirmé. Merci pour l'indice. J'avoue que l'erreur que j'avais ne me parlait pas beaucoup, mais j'aurais sans doute du trouver seul quand même.
Merci
Ben voyons :) Merci à toi.
Christophe PEREZ
Bon, je reviens sur le sujet, parce que finalement, ça ne fonctionne pas mieux. J'ai du bâcler mes tests... Le Wed, 21 Dec 2016 10:27:21 +0000, Nicolas George a écrit :
En revanche, il y a d'autres points à surveiller. Certaines versions de SSH garder la connexion ouverte tant qu'ils voient un file descriptor ouvert, donc sois bien sûr d'avoir fermé stdin, stdout et stderr dès que possible.
Alors là, même si je vois un peu l'idée, je ne sais pas trop ce que je dois faire.
Certains versions de SSH ont aussi des trucs bizarres avec le terminal de contrôle, donc setsid peut aider.
Je ne connais pas. J'ai commencé à regarder, mais sans succès pour l'instant. Déjà avec un sleep seul, je ne parviens pas à obtenir le résultat souhaité. distant.sh : ------------------------------- %< ---------------------------- setsid sleep 5 < /dev/null > /dev/null 2 > /dev/null ------------------------------- %< ---------------------------- lancé par un ssh -x $DISTUSER@$HOST distant.sh ne me rend pas la main avant les 5sec. De toutes les façons, je me rends compte qu'un script contenant juste : sleep 5 & ne me rend pas la main si exécuté à distance par ssh, alors qu'il rend bien la main si exécuté en local. Ensuite, je ne sais pas comment cumuler ça avec le { } qui regroupe mes commandes. En tout cas, j'ai réussi à synthétiser mon besoin : Comment, dans un script bash lancé à distance par ssh, différer l'exécution d'un ensemble de commandes tout en rendant la main ?
Bon, je reviens sur le sujet, parce que finalement, ça ne fonctionne pas
mieux. J'ai du bâcler mes tests...
Le Wed, 21 Dec 2016 10:27:21 +0000, Nicolas George a écrit :
En revanche, il y a d'autres points à surveiller. Certaines versions de
SSH garder la connexion ouverte tant qu'ils voient un file descriptor
ouvert, donc sois bien sûr d'avoir fermé stdin, stdout et stderr dès que
possible.
Alors là, même si je vois un peu l'idée, je ne sais pas trop ce que je
dois faire.
Certains versions de SSH ont aussi des trucs bizarres avec le terminal
de contrôle, donc setsid peut aider.
Je ne connais pas. J'ai commencé à regarder, mais sans succès pour
l'instant.
Déjà avec un sleep seul, je ne parviens pas à obtenir le résultat
souhaité.
distant.sh :
------------------------------- %< ----------------------------
setsid sleep 5 < /dev/null > /dev/null 2 > /dev/null
------------------------------- %< ----------------------------
lancé par un ssh -x $DISTUSER@$HOST distant.sh ne me rend pas la main
avant les 5sec.
De toutes les façons, je me rends compte qu'un script contenant juste :
sleep 5 &
ne me rend pas la main si exécuté à distance par ssh, alors qu'il rend
bien la main si exécuté en local.
Ensuite, je ne sais pas comment cumuler ça avec le { } qui regroupe mes
commandes.
En tout cas, j'ai réussi à synthétiser mon besoin :
Comment, dans un script bash lancé à distance par ssh, différer
l'exécution d'un ensemble de commandes tout en rendant la main ?
Bon, je reviens sur le sujet, parce que finalement, ça ne fonctionne pas mieux. J'ai du bâcler mes tests... Le Wed, 21 Dec 2016 10:27:21 +0000, Nicolas George a écrit :
En revanche, il y a d'autres points à surveiller. Certaines versions de SSH garder la connexion ouverte tant qu'ils voient un file descriptor ouvert, donc sois bien sûr d'avoir fermé stdin, stdout et stderr dès que possible.
Alors là, même si je vois un peu l'idée, je ne sais pas trop ce que je dois faire.
Certains versions de SSH ont aussi des trucs bizarres avec le terminal de contrôle, donc setsid peut aider.
Je ne connais pas. J'ai commencé à regarder, mais sans succès pour l'instant. Déjà avec un sleep seul, je ne parviens pas à obtenir le résultat souhaité. distant.sh : ------------------------------- %< ---------------------------- setsid sleep 5 < /dev/null > /dev/null 2 > /dev/null ------------------------------- %< ---------------------------- lancé par un ssh -x $DISTUSER@$HOST distant.sh ne me rend pas la main avant les 5sec. De toutes les façons, je me rends compte qu'un script contenant juste : sleep 5 & ne me rend pas la main si exécuté à distance par ssh, alors qu'il rend bien la main si exécuté en local. Ensuite, je ne sais pas comment cumuler ça avec le { } qui regroupe mes commandes. En tout cas, j'ai réussi à synthétiser mon besoin : Comment, dans un script bash lancé à distance par ssh, différer l'exécution d'un ensemble de commandes tout en rendant la main ?
