Bonjour,
Je débute en venant de DOS et je comprends pas bien comment dans un shell
positionner une variable pour qu'elle soit valide en sortie du shell
exemple
#!/bin/sh
TOTO=123
echo $TOTO
j'ai bien 123
mais si je lance manuellement echo $TOTO , je n'ai plus rien
Une autre question , est ce qu'il est possible de lancer un executable en
tache de fond a partir d'un shell
#!/bin/sh
Monexe1
Monexe2
Monexe3
en fait je veux lancer un executable (Monexe2)qui ne s'arrête que 10
minutes plus tard. mais je veux que le shell sorte directement.
Screen permet de lancer un «shell virtuel» dans lequel on lance des
... un shell (réél) dans un terminal virtuel
Nicolas George
Je réponds ici faute de mieux, c'est uen réponse générale.
Personnellement, je n'ai jamais trouvé que la commande nohup soit une bonne idée. Il faut bien voir ce que fait cette commande :
- Une redirection des entrées/sorties. Ouais. C'est utile, clairement, mais une redirection des entrées/sorties, on peut déjà faire avec < et >, pas vraiment besoin d'une commande pour faire ça.
- Placer SIGHUP à SIG_IGN. Beurk. Ce n'est pas comme ça qu'on détache un processus d'un terminal, la bonne méthode (sur les systèmes qui suivent Single Unix) est setsid.
D'ailleurs, Linux vient avec une commande setsid qui fait précisément ça. Je trouve dommage qu'elle ne soit pas plus répandue.
Je réponds ici faute de mieux, c'est uen réponse générale.
Personnellement, je n'ai jamais trouvé que la commande nohup soit une bonne
idée. Il faut bien voir ce que fait cette commande :
- Une redirection des entrées/sorties. Ouais. C'est utile, clairement, mais
une redirection des entrées/sorties, on peut déjà faire avec < et >, pas
vraiment besoin d'une commande pour faire ça.
- Placer SIGHUP à SIG_IGN. Beurk. Ce n'est pas comme ça qu'on détache un
processus d'un terminal, la bonne méthode (sur les systèmes qui suivent
Single Unix) est setsid.
D'ailleurs, Linux vient avec une commande setsid qui fait précisément ça. Je
trouve dommage qu'elle ne soit pas plus répandue.
Je réponds ici faute de mieux, c'est uen réponse générale.
Personnellement, je n'ai jamais trouvé que la commande nohup soit une bonne idée. Il faut bien voir ce que fait cette commande :
- Une redirection des entrées/sorties. Ouais. C'est utile, clairement, mais une redirection des entrées/sorties, on peut déjà faire avec < et >, pas vraiment besoin d'une commande pour faire ça.
- Placer SIGHUP à SIG_IGN. Beurk. Ce n'est pas comme ça qu'on détache un processus d'un terminal, la bonne méthode (sur les systèmes qui suivent Single Unix) est setsid.
D'ailleurs, Linux vient avec une commande setsid qui fait précisément ça. Je trouve dommage qu'elle ne soit pas plus répandue.
gregg
Paul Gaborit wrote: Ce comportement n'est pas dépendant du terminal mais du shell.
Certains shells (en gros ceux de la famille 'sh') nécessitent le passage par 'nohup' (car à leur mort ils envoient un signal HUP à tous leurs fils).
D'autres (en gros ceux de la famille 'csh') gèrent le 'nohup' tout seul en interne et, à leur mort, détachent les jobs en cours (les éventuelles sorties de ces jobs sont alors redirigées vers /dev/null).
Il me semble que bash a ce dernier comportement. (Pourtant de la famille des sh) (mmmh, enfin, de quelle famille est bash exactement, parfois je me demande...)
Reste que, comme c'est paramétrable, ça se configure dans le .rc du shell.
++
Paul Gaborit wrote:
Ce comportement n'est pas dépendant du terminal mais du shell.
Certains shells (en gros ceux de la famille 'sh') nécessitent le passage par
'nohup' (car à leur mort ils envoient un signal HUP à tous leurs
fils).
D'autres (en gros ceux de la famille 'csh') gèrent le 'nohup' tout seul en
interne et, à leur mort, détachent les jobs en cours (les éventuelles sorties
de ces jobs sont alors redirigées vers /dev/null).
Il me semble que bash a ce dernier comportement.
(Pourtant de la famille des sh) (mmmh, enfin, de quelle famille est bash
exactement, parfois je me demande...)
Reste que, comme c'est paramétrable, ça se configure dans le .rc du shell.
Paul Gaborit wrote: Ce comportement n'est pas dépendant du terminal mais du shell.
Certains shells (en gros ceux de la famille 'sh') nécessitent le passage par 'nohup' (car à leur mort ils envoient un signal HUP à tous leurs fils).
D'autres (en gros ceux de la famille 'csh') gèrent le 'nohup' tout seul en interne et, à leur mort, détachent les jobs en cours (les éventuelles sorties de ces jobs sont alors redirigées vers /dev/null).
Il me semble que bash a ce dernier comportement. (Pourtant de la famille des sh) (mmmh, enfin, de quelle famille est bash exactement, parfois je me demande...)
Reste que, comme c'est paramétrable, ça se configure dans le .rc du shell.
++
Thomas Labourdette
Rakotomandimby (R12y) Mihamina a écrit le Jeudi 07 Avril 2005 15:38 :
Une autre question , est ce qu'il est possible de lancer un executable en tache de fond a partir d'un shell < snip >
en fait je veux lancer un executable (Monexe2)qui ne s'arrête que 10 minutes plus tard. mais je veux que le shell sorte directement.
Il suffit de mettre un "&" après le nom de la commande.
Si c'est à partir d'un xterm, si tu quitte le xterm, la commande lancée en background s'aretera. Ce n'est pas systématique, c'est comme ça sous certaines conditions, que je n'ai pas le temps de reproduire
Chez moi (xterm, bash) : si je ferme le xterm avec la commande exit, l'application lancée en background continue, par contre si je click sur la croix en haute à droite du xterm, l'application s'arrête en même temps que le xterm.
Merci à Nicolas George pour la commande setsid.
@+ -- Judas BORPEUR (signature aléatoire) Sur mon bulletin scolaire : "Un vrai touriste aurait au moins pris des photos."
Rakotomandimby (R12y) Mihamina a écrit le Jeudi 07 Avril 2005 15:38 :
Une autre question , est ce qu'il est possible de lancer un executable
en tache de fond a partir d'un shell
< snip >
en fait je veux lancer un executable (Monexe2)qui ne s'arrête que 10
minutes plus tard. mais je veux que le shell sorte directement.
Il suffit de mettre un "&" après le nom de la commande.
Si c'est à partir d'un xterm, si tu quitte le xterm, la commande lancée
en background s'aretera. Ce n'est pas systématique, c'est comme ça sous
certaines conditions, que je n'ai pas le temps de reproduire
Chez moi (xterm, bash) : si je ferme le xterm avec la commande exit,
l'application lancée en background continue, par contre si je click sur la
croix en haute à droite du xterm, l'application s'arrête en même temps que
le xterm.
Merci à Nicolas George pour la commande setsid.
@+
--
Judas BORPEUR (signature aléatoire)
Sur mon bulletin scolaire :
"Un vrai touriste aurait au moins pris des photos."
Une autre question , est ce qu'il est possible de lancer un executable en tache de fond a partir d'un shell < snip >
en fait je veux lancer un executable (Monexe2)qui ne s'arrête que 10 minutes plus tard. mais je veux que le shell sorte directement.
Il suffit de mettre un "&" après le nom de la commande.
Si c'est à partir d'un xterm, si tu quitte le xterm, la commande lancée en background s'aretera. Ce n'est pas systématique, c'est comme ça sous certaines conditions, que je n'ai pas le temps de reproduire
Chez moi (xterm, bash) : si je ferme le xterm avec la commande exit, l'application lancée en background continue, par contre si je click sur la croix en haute à droite du xterm, l'application s'arrête en même temps que le xterm.
Merci à Nicolas George pour la commande setsid.
@+ -- Judas BORPEUR (signature aléatoire) Sur mon bulletin scolaire : "Un vrai touriste aurait au moins pris des photos."
Stephane Dupille
Je réponds ici faute de mieux, c'est uen réponse générale. Personnellement, je n'ai jamais trouvé que la commande nohup soit une bonne idée. Il faut bien voir ce que fait cette commande : - Une redirection des entrées/sorties. Ouais. C'est utile, clairement, mais une redirection des entrées/sorties, on peut déjà faire avec < et >, pas vraiment besoin d'une commande pour faire ça.
Oui.
- Placer SIGHUP à SIG_IGN. Beurk. Ce n'est pas comme ça qu'on détache un processus d'un terminal, la bonne méthode (sur les systèmes qui suivent Single Unix) est setsid.
[gimli] ~> setsid zsh: command not found: setsid
setsid, c'est bien quand on fait soi-même un programme qui est censé se comporter en daemon. nohup ne sert pas à ça : il sert à lancer n'importe quelle commande en tache de fond. Par exemple, il m'est déjà arrivé de lancer des grosses applis de calculs qui tournent une nuit entière, et qui ne doit pas être interrompu quand je ne suis pas là. Dans ce cas, la réponse, c'est nohup, pas setsid.
D'ailleurs, Linux vient avec une commande setsid qui fait précisément ça. Je trouve dommage qu'elle ne soit pas plus répandue.
C'est dans les BSD aussi, mais c'est une fonction de la libc, pas une commande. Ce n'est pas le même usage.
-- je hais 1/ les assistantes sociales, 2/ les ivrognes, 3/ les sales cons en uniforme et 4/ tout ce qui ressemble à un humain de base. Et je suis armé. Bonne nuit, -+- Or in <http://www.le-gnu.net> - Nuit de Chine, nuit caline -+-
Je réponds ici faute de mieux, c'est uen réponse générale.
Personnellement, je n'ai jamais trouvé que la commande nohup soit une bonne
idée. Il faut bien voir ce que fait cette commande :
- Une redirection des entrées/sorties. Ouais. C'est utile, clairement, mais
une redirection des entrées/sorties, on peut déjà faire avec < et >, pas
vraiment besoin d'une commande pour faire ça.
Oui.
- Placer SIGHUP à SIG_IGN. Beurk. Ce n'est pas comme ça qu'on détache un
processus d'un terminal, la bonne méthode (sur les systèmes qui suivent
Single Unix) est setsid.
[gimli] ~> setsid
zsh: command not found: setsid
setsid, c'est bien quand on fait soi-même un programme qui est censé
se comporter en daemon. nohup ne sert pas à ça : il sert à lancer
n'importe quelle commande en tache de fond. Par exemple, il m'est déjà
arrivé de lancer des grosses applis de calculs qui tournent une nuit
entière, et qui ne doit pas être interrompu quand je ne suis pas là.
Dans ce cas, la réponse, c'est nohup, pas setsid.
D'ailleurs, Linux vient avec une commande setsid qui fait précisément ça. Je
trouve dommage qu'elle ne soit pas plus répandue.
C'est dans les BSD aussi, mais c'est une fonction de la libc, pas
une commande. Ce n'est pas le même usage.
--
je hais 1/ les assistantes sociales, 2/ les ivrognes, 3/ les sales
cons en uniforme et 4/ tout ce qui ressemble à un humain de base.
Et je suis armé. Bonne nuit,
-+- Or in <http://www.le-gnu.net> - Nuit de Chine, nuit caline -+-
Je réponds ici faute de mieux, c'est uen réponse générale. Personnellement, je n'ai jamais trouvé que la commande nohup soit une bonne idée. Il faut bien voir ce que fait cette commande : - Une redirection des entrées/sorties. Ouais. C'est utile, clairement, mais une redirection des entrées/sorties, on peut déjà faire avec < et >, pas vraiment besoin d'une commande pour faire ça.
Oui.
- Placer SIGHUP à SIG_IGN. Beurk. Ce n'est pas comme ça qu'on détache un processus d'un terminal, la bonne méthode (sur les systèmes qui suivent Single Unix) est setsid.
[gimli] ~> setsid zsh: command not found: setsid
setsid, c'est bien quand on fait soi-même un programme qui est censé se comporter en daemon. nohup ne sert pas à ça : il sert à lancer n'importe quelle commande en tache de fond. Par exemple, il m'est déjà arrivé de lancer des grosses applis de calculs qui tournent une nuit entière, et qui ne doit pas être interrompu quand je ne suis pas là. Dans ce cas, la réponse, c'est nohup, pas setsid.
D'ailleurs, Linux vient avec une commande setsid qui fait précisément ça. Je trouve dommage qu'elle ne soit pas plus répandue.
C'est dans les BSD aussi, mais c'est une fonction de la libc, pas une commande. Ce n'est pas le même usage.
-- je hais 1/ les assistantes sociales, 2/ les ivrognes, 3/ les sales cons en uniforme et 4/ tout ce qui ressemble à un humain de base. Et je suis armé. Bonne nuit, -+- Or in <http://www.le-gnu.net> - Nuit de Chine, nuit caline -+-
Stephane Dupille
Non, il *suffit* d'utiliser nohup. Avec le shell bash par exemple, on peut utiliser la commande interne disown avec l'option -h (man bash, ou help disown pour plus de détails).
disown, c'est pas spécifique à zsh ? Le pb de disown, c'est qu'on doive l'utiliser après que la commande a été lancée, et ce n'est pas toujours facile à contrôler dans un script.
-- (Pour mesurer l'intelligence dans fufe) Facile: un test de Turing. Tu prends une personne dans un groupe sensé, une personne dans fufe. Dès que tu arrives à repérer le trolleur tu détruis le groupe. -+- Ol in Guide du Neuneu Usenet : Maffacre à la fufonneuse -+-
Non, il *suffit* d'utiliser nohup. Avec le shell bash par exemple, on
peut utiliser la commande interne disown avec l'option -h (man bash,
ou help disown pour plus de détails).
disown, c'est pas spécifique à zsh ? Le pb de disown, c'est qu'on
doive l'utiliser après que la commande a été lancée, et ce n'est pas
toujours facile à contrôler dans un script.
--
(Pour mesurer l'intelligence dans fufe) Facile: un test de Turing. Tu
prends une personne dans un groupe sensé, une personne dans fufe. Dès
que tu arrives à repérer le trolleur tu détruis le groupe.
-+- Ol in Guide du Neuneu Usenet : Maffacre à la fufonneuse -+-
Non, il *suffit* d'utiliser nohup. Avec le shell bash par exemple, on peut utiliser la commande interne disown avec l'option -h (man bash, ou help disown pour plus de détails).
disown, c'est pas spécifique à zsh ? Le pb de disown, c'est qu'on doive l'utiliser après que la commande a été lancée, et ce n'est pas toujours facile à contrôler dans un script.
-- (Pour mesurer l'intelligence dans fufe) Facile: un test de Turing. Tu prends une personne dans un groupe sensé, une personne dans fufe. Dès que tu arrives à repérer le trolleur tu détruis le groupe. -+- Ol in Guide du Neuneu Usenet : Maffacre à la fufonneuse -+-
Sébastien Kirche
Le 7 Apr 2005, Laurent Wacrenier a dit :
... un shell (réél) dans un terminal virtuel
Toutes mes confuses. J'ai tendance à mélanger console, terminal et shell dans une même entité. Et je nomme souvent l'un pour l'autre.
-- Sébastien Kirche
Le 7 Apr 2005, Laurent Wacrenier a dit :
... un shell (réél) dans un terminal virtuel
Toutes mes confuses. J'ai tendance à mélanger console, terminal et shell
dans une même entité. Et je nomme souvent l'un pour l'autre.
Toutes mes confuses. J'ai tendance à mélanger console, terminal et shell dans une même entité. Et je nomme souvent l'un pour l'autre.
C'est parce que tu n'as pas assez travaillé sur un vrai terminal, comme le VT100 (http://www.vt100.net/)
xterm, screen ne sont que des émulations logicielles.
Loïc Restoux
Le 07 avr, à 15:29, Sébastien Kirche papotait :
C'est (screen) très pratique pour démarrer par exemple un téléchargement depuis un xterm, détacher, puis plus tard et de l'extérieur se rebrancher dessus via un ssh pour aller voir où c'en est.
Moi j'y lance des clients irc ou Usenet.
Autre point pratique, on peut lancer plusieurs shells dans le même screen et switcher de l'un à l'autre.
On peut aussi partager l'affichage entre plusieurs intervenants. Pratique pour une démonstration dans un terminal.
-- Y'en a aussi
Le 07 avr, à 15:29, Sébastien Kirche papotait :
C'est (screen) très pratique pour démarrer par exemple un
téléchargement depuis un xterm, détacher, puis plus tard et de
l'extérieur se rebrancher dessus via un ssh pour aller voir où
c'en est.
Moi j'y lance des clients irc ou Usenet.
Autre point pratique, on peut lancer plusieurs shells dans le
même screen et switcher de l'un à l'autre.
On peut aussi partager l'affichage entre plusieurs intervenants.
Pratique pour une démonstration dans un terminal.
C'est (screen) très pratique pour démarrer par exemple un téléchargement depuis un xterm, détacher, puis plus tard et de l'extérieur se rebrancher dessus via un ssh pour aller voir où c'en est.
Moi j'y lance des clients irc ou Usenet.
Autre point pratique, on peut lancer plusieurs shells dans le même screen et switcher de l'un à l'autre.
On peut aussi partager l'affichage entre plusieurs intervenants. Pratique pour une démonstration dans un terminal.
Autre point pratique, on peut lancer plusieurs shells dans le même screen et switcher de l'un à l'autre.
On peut aussi partager l'affichage entre plusieurs intervenants. Pratique pour une démonstration dans un terminal.
On peut aussi détacher toute le session 'screen' du terminal courant puis rattacher cette session sur un autre terminal. C'est pratique par exemple lorsqu'on commence quelque chose au boulot et qu'on veut le terminer de chez soi...ou l'inverse ;-)
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Autre point pratique, on peut lancer plusieurs shells dans le
même screen et switcher de l'un à l'autre.
On peut aussi partager l'affichage entre plusieurs intervenants.
Pratique pour une démonstration dans un terminal.
On peut aussi détacher toute le session 'screen' du terminal courant puis
rattacher cette session sur un autre terminal. C'est pratique par exemple
lorsqu'on commence quelque chose au boulot et qu'on veut le terminer de chez
soi...ou l'inverse ;-)
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Autre point pratique, on peut lancer plusieurs shells dans le même screen et switcher de l'un à l'autre.
On peut aussi partager l'affichage entre plusieurs intervenants. Pratique pour une démonstration dans un terminal.
On peut aussi détacher toute le session 'screen' du terminal courant puis rattacher cette session sur un autre terminal. C'est pratique par exemple lorsqu'on commence quelque chose au boulot et qu'on veut le terminer de chez soi...ou l'inverse ;-)
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
