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.
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 < snip >
C'est normal : votre script va lancer un nouveau processus, un nouveau shell. La variable sera positionné dans le sous-shell, qui ne peut pas transmettre une variable à son processus parent. De retour dans le shell père, vous avez perdu la variable déclarée dans le shell fils.
Une solution, est de lancer le script dans le shell courant, et non de lancer un shell fils, en utilisant la commande "." ou "source". Par exemple : # source <script> 123 # echo $TOTO 123
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. Il peut être pertinent également de faire précéder la commande par "nohup", selon les cas, et selon les shells manipulés.
--
ou trouver forum de rencontre et d'echangisme sur liberty .surf? On a déjà tellement du mal à se connecter et à avoir des données entre
18h00 et 24h00 sur LIBERTYSURF comment veux tu faire des rencontres ?? -+- Pierrot in GNU - Neuneu confond liberty.surf et liberty.nage -+-
Bonjour,
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
< snip >
C'est normal : votre script va lancer un nouveau processus, un
nouveau shell. La variable sera positionné dans le sous-shell, qui ne
peut pas transmettre une variable à son processus parent. De retour
dans le shell père, vous avez perdu la variable déclarée dans le shell
fils.
Une solution, est de lancer le script dans le shell courant, et non
de lancer un shell fils, en utilisant la commande "." ou "source". Par
exemple :
# source <script>
123
# echo $TOTO
123
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. Il peut être
pertinent également de faire précéder la commande par "nohup", selon
les cas, et selon les shells manipulés.
--
ou trouver forum de rencontre et d'echangisme sur liberty .surf?
On a déjà tellement du mal à se connecter et à avoir des données entre
18h00 et 24h00 sur LIBERTYSURF comment veux tu faire des rencontres ??
-+- Pierrot in GNU - Neuneu confond liberty.surf et liberty.nage -+-
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 < snip >
C'est normal : votre script va lancer un nouveau processus, un nouveau shell. La variable sera positionné dans le sous-shell, qui ne peut pas transmettre une variable à son processus parent. De retour dans le shell père, vous avez perdu la variable déclarée dans le shell fils.
Une solution, est de lancer le script dans le shell courant, et non de lancer un shell fils, en utilisant la commande "." ou "source". Par exemple : # source <script> 123 # echo $TOTO 123
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. Il peut être pertinent également de faire précéder la commande par "nohup", selon les cas, et selon les shells manipulés.
--
ou trouver forum de rencontre et d'echangisme sur liberty .surf? On a déjà tellement du mal à se connecter et à avoir des données entre
18h00 et 24h00 sur LIBERTYSURF comment veux tu faire des rencontres ?? -+- Pierrot in GNU - Neuneu confond liberty.surf et liberty.nage -+-
Grosdebutant
Impeccable c'est exactement ce que je voulais merci
Le Thu, 07 Apr 2005 11:15:19 +0200, Stephane Dupille a écrit :
Bonjour,
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 < snip >
C'est normal : votre script va lancer un nouveau processus, un nouveau shell. La variable sera positionné dans le sous-shell, qui ne peut pas transmettre une variable à son processus parent. De retour dans le shell père, vous avez perdu la variable déclarée dans le shell fils.
Une solution, est de lancer le script dans le shell courant, et non de lancer un shell fils, en utilisant la commande "." ou "source". Par exemple : # source <script> 123 # echo $TOTO 123
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. Il peut être pertinent également de faire précéder la commande par "nohup", selon les cas, et selon les shells manipulés.
Impeccable
c'est exactement ce que je voulais
merci
Le Thu, 07 Apr 2005 11:15:19 +0200, Stephane Dupille a écrit :
Bonjour,
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
< snip >
C'est normal : votre script va lancer un nouveau processus, un
nouveau shell. La variable sera positionné dans le sous-shell, qui ne
peut pas transmettre une variable à son processus parent. De retour
dans le shell père, vous avez perdu la variable déclarée dans le shell
fils.
Une solution, est de lancer le script dans le shell courant, et non
de lancer un shell fils, en utilisant la commande "." ou "source". Par
exemple :
# source <script>
123
# echo $TOTO
123
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. Il peut être
pertinent également de faire précéder la commande par "nohup", selon
les cas, et selon les shells manipulés.
Impeccable c'est exactement ce que je voulais merci
Le Thu, 07 Apr 2005 11:15:19 +0200, Stephane Dupille a écrit :
Bonjour,
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 < snip >
C'est normal : votre script va lancer un nouveau processus, un nouveau shell. La variable sera positionné dans le sous-shell, qui ne peut pas transmettre une variable à son processus parent. De retour dans le shell père, vous avez perdu la variable déclarée dans le shell fils.
Une solution, est de lancer le script dans le shell courant, et non de lancer un shell fils, en utilisant la commande "." ou "source". Par exemple : # source <script> 123 # echo $TOTO 123
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. Il peut être pertinent également de faire précéder la commande par "nohup", selon les cas, et selon les shells manipulés.
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, mais le '&' en fin de ligne de commande n'est pas éfficace "tout le temps".
-- Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois! La preuve http://www.google.fr/search?q=serveur+dedie Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
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, mais le '&'
en fin de ligne de commande n'est pas éfficace "tout le temps".
--
Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois!
La preuve http://www.google.fr/search?q=serveur+dedie
Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
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, mais le '&' en fin de ligne de commande n'est pas éfficace "tout le temps".
-- Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois! La preuve http://www.google.fr/search?q=serveur+dedie Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
Stephane Dupille
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, mais le '&' en fin de ligne de commande n'est pas éfficace "tout le temps".
C'est bien pour ça que j'avais ajouté, que selon les cas, il peut être utile d'utiliser « nohup », qui sert justement à éviter ça. Ça dépend de plusieurs facteurs : . si le gestionnaire de terminal envoi un sighup ou non lorsqu'il arrête la session ; . la façon dont le shell transmet ou non ce signal aux fils.
--
Je cherche à calculer la distance de deux points sur une sphère. J'aurais peut-être çà, mais il faut absolument que les points
soient à la même distance l'un de l'autre. -+- DC in GNU: Savoir sphère le point -+-
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, mais le '&'
en fin de ligne de commande n'est pas éfficace "tout le temps".
C'est bien pour ça que j'avais ajouté, que selon les cas, il peut
être utile d'utiliser « nohup », qui sert justement à éviter ça. Ça
dépend de plusieurs facteurs :
. si le gestionnaire de terminal envoi un sighup ou non lorsqu'il
arrête la session ;
. la façon dont le shell transmet ou non ce signal aux fils.
--
Je cherche à calculer la distance de deux points sur une sphère.
J'aurais peut-être çà, mais il faut absolument que les points
soient à la même distance l'un de l'autre.
-+- DC in GNU: Savoir sphère le point -+-
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, mais le '&' en fin de ligne de commande n'est pas éfficace "tout le temps".
C'est bien pour ça que j'avais ajouté, que selon les cas, il peut être utile d'utiliser « nohup », qui sert justement à éviter ça. Ça dépend de plusieurs facteurs : . si le gestionnaire de terminal envoi un sighup ou non lorsqu'il arrête la session ; . la façon dont le shell transmet ou non ce signal aux fils.
--
Je cherche à calculer la distance de deux points sur une sphère. J'aurais peut-être çà, mais il faut absolument que les points
soient à la même distance l'un de l'autre. -+- DC in GNU: Savoir sphère le point -+-
Sébastien Kirche
Le 7 Apr 2005, Rakotomandimby Mihamina vraute :
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, mais le '&' en fin de ligne de commande n'est pas éfficace "tout le temps".
Sauf si tu précède la commande de nohup comme l'a indiqué Stéphane Dupille.
Il faut juste voir si la commande peut être verbeuse (erreurs) car ça peut amener des surprise de remplissage disque intempestif, la sortie allant dans un fichier.
-- Sébastien Kirche
Le 7 Apr 2005, Rakotomandimby Mihamina vraute :
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, mais le '&'
en fin de ligne de commande n'est pas éfficace "tout le temps".
Sauf si tu précède la commande de nohup comme l'a indiqué Stéphane Dupille.
Il faut juste voir si la commande peut être verbeuse (erreurs) car ça peut
amener des surprise de remplissage disque intempestif, la sortie allant dans
un fichier.
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, mais le '&' en fin de ligne de commande n'est pas éfficace "tout le temps".
Sauf si tu précède la commande de nohup comme l'a indiqué Stéphane Dupille.
Il faut juste voir si la commande peut être verbeuse (erreurs) car ça peut amener des surprise de remplissage disque intempestif, la sortie allant dans un fichier.
C'est bien pour ça que j'avais ajouté, que selon les cas, il peut être utile d'utiliser « nohup », qui sert justement à éviter ça.
Ah! d'accord. Je me souviens qu'il y avait d'autres personnes qui avaient ce problème et, _si_ ma mémoire est bonne (remarque, à 25 ans y a pas de raisons...), on lui a proposé "screen". Je ne connaissait pas nohup.
Voilà. Désolé hein... ;-)
-- Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois! La preuve http://www.google.fr/search?q=serveur+dedie Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
C'est bien pour ça que j'avais ajouté, que selon les cas, il peut
être utile d'utiliser « nohup », qui sert justement à éviter ça.
Ah! d'accord.
Je me souviens qu'il y avait d'autres personnes qui avaient ce problème
et, _si_ ma mémoire est bonne (remarque, à 25 ans y a pas de
raisons...), on lui a proposé "screen". Je ne connaissait pas nohup.
Voilà. Désolé hein... ;-)
--
Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois!
La preuve http://www.google.fr/search?q=serveur+dedie
Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
C'est bien pour ça que j'avais ajouté, que selon les cas, il peut être utile d'utiliser « nohup », qui sert justement à éviter ça.
Ah! d'accord. Je me souviens qu'il y avait d'autres personnes qui avaient ce problème et, _si_ ma mémoire est bonne (remarque, à 25 ans y a pas de raisons...), on lui a proposé "screen". Je ne connaissait pas nohup.
Voilà. Désolé hein... ;-)
-- Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois! La preuve http://www.google.fr/search?q=serveur+dedie Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
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, mais le '&' en fin de ligne de commande n'est pas éfficace "tout le temps".
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).
D'autres enfin (au moins 'zsh' si mes souvenirs sont bons) permettent de choisir le comportement voulu...
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
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, mais le '&'
en fin de ligne de commande n'est pas éfficace "tout le temps".
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).
D'autres enfin (au moins 'zsh' si mes souvenirs sont bons) permettent de
choisir le comportement voulu...
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
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, mais le '&' en fin de ligne de commande n'est pas éfficace "tout le temps".
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).
D'autres enfin (au moins 'zsh' si mes souvenirs sont bons) permettent de choisir le comportement voulu...
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Stephane Dupille
Je me souviens qu'il y avait d'autres personnes qui avaient ce problème et, _si_ ma mémoire est bonne (remarque, à 25 ans y a pas de raisons...), on lui a proposé "screen". Je ne connaissait pas nohup.
screen, c'est autre chose. En fait, si c'est un truc plus ou moins interactif, et qu'on veut le reprendre plus tard, alors il faut utiliser screen. Si c'est un truc que l'on lance en tache de fond, et qu'on souhaite oublier jusqu'à ce qu'il ait fini, il faut utiliser nohup.
Il faut prendre également en compte que nohup est en général livré avec le système, pas screen.
Voilà. Désolé hein... ;-)
Mais il n'y a pas d'mal ! Mais si tu tiens vraiment à te faire pardonner un truc, ça tombe bien : j'ai soif ! :*)
-- Bien reçu message via groupes discussion, je te répond avec la touche " répondre au groupe " en ayant sélectionné ton message. J'espère que tu le recevra dans ta boîte de réception. Le café est en préparation. -+- in Guide du Neuneu Usenet - Open up, open up -+-
Je me souviens qu'il y avait d'autres personnes qui avaient ce problème
et, _si_ ma mémoire est bonne (remarque, à 25 ans y a pas de
raisons...), on lui a proposé "screen". Je ne connaissait pas nohup.
screen, c'est autre chose. En fait, si c'est un truc plus ou moins
interactif, et qu'on veut le reprendre plus tard, alors il faut
utiliser screen. Si c'est un truc que l'on lance en tache de fond, et
qu'on souhaite oublier jusqu'à ce qu'il ait fini, il faut utiliser
nohup.
Il faut prendre également en compte que nohup est en général livré
avec le système, pas screen.
Voilà. Désolé hein... ;-)
Mais il n'y a pas d'mal ! Mais si tu tiens vraiment à te faire
pardonner un truc, ça tombe bien : j'ai soif ! :*)
--
Bien reçu message via groupes discussion, je te répond avec la touche "
répondre au groupe " en ayant sélectionné ton message. J'espère que tu le
recevra dans ta boîte de réception. Le café est en préparation.
-+- in Guide du Neuneu Usenet - Open up, open up -+-
Je me souviens qu'il y avait d'autres personnes qui avaient ce problème et, _si_ ma mémoire est bonne (remarque, à 25 ans y a pas de raisons...), on lui a proposé "screen". Je ne connaissait pas nohup.
screen, c'est autre chose. En fait, si c'est un truc plus ou moins interactif, et qu'on veut le reprendre plus tard, alors il faut utiliser screen. Si c'est un truc que l'on lance en tache de fond, et qu'on souhaite oublier jusqu'à ce qu'il ait fini, il faut utiliser nohup.
Il faut prendre également en compte que nohup est en général livré avec le système, pas screen.
Voilà. Désolé hein... ;-)
Mais il n'y a pas d'mal ! Mais si tu tiens vraiment à te faire pardonner un truc, ça tombe bien : j'ai soif ! :*)
-- Bien reçu message via groupes discussion, je te répond avec la touche " répondre au groupe " en ayant sélectionné ton message. J'espère que tu le recevra dans ta boîte de réception. Le café est en préparation. -+- in Guide du Neuneu Usenet - Open up, open up -+-
Sébastien Kirche
Le 7 Apr 2005, Rakotomandimby Mihamina vraute :
Je me souviens qu'il y avait d'autres personnes qui avaient ce problème et, _si_ ma mémoire est bonne (remarque, à 25 ans y a pas de raisons...), on lui a proposé "screen". Je ne connaissait pas nohup.
Ce n'est pas tout à fait le même usage, même si ça peut se ressembler.
Comme l'a développé Paul Gaborit, nohup permet de détacher une commande, un processus du shell qui l'a lancé pour qu'à la mort du shell la commande si ele dure ou le programme lancé ne meure pas avec lui. Mais une fois détaché, on ne peut plus interagir avec, on peut tout juste aller voir s'il y a une sortie dans le fichier généré par nohup à cet effet.
Screen permet de lancer un «shell virtuel» dans lequel on lance des commandes ou des programmes comme d'habitude mais que l'on peut détacher (comme pour nohup le process ou la commande suit son cours) mais sur lequel on peut se rebrancher. Soit plus tard, soit d'un autre terminal (vt mode texte ou xterm).
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.
Autre point pratique, on peut lancer plusieurs shells dans le même screen et switcher de l'un à l'autre.
-- Sébastien Kirche
Le 7 Apr 2005, Rakotomandimby Mihamina vraute :
Je me souviens qu'il y avait d'autres personnes qui avaient ce problème
et, _si_ ma mémoire est bonne (remarque, à 25 ans y a pas de
raisons...), on lui a proposé "screen". Je ne connaissait pas nohup.
Ce n'est pas tout à fait le même usage, même si ça peut se ressembler.
Comme l'a développé Paul Gaborit, nohup permet de détacher une commande, un
processus du shell qui l'a lancé pour qu'à la mort du shell la commande si
ele dure ou le programme lancé ne meure pas avec lui. Mais une fois détaché,
on ne peut plus interagir avec, on peut tout juste aller voir s'il y a une
sortie dans le fichier généré par nohup à cet effet.
Screen permet de lancer un «shell virtuel» dans lequel on lance des
commandes ou des programmes comme d'habitude mais que l'on peut détacher
(comme pour nohup le process ou la commande suit son cours) mais sur lequel
on peut se rebrancher. Soit plus tard, soit d'un autre terminal (vt mode
texte ou xterm).
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.
Autre point pratique, on peut lancer plusieurs shells dans le même screen et
switcher de l'un à l'autre.
Je me souviens qu'il y avait d'autres personnes qui avaient ce problème et, _si_ ma mémoire est bonne (remarque, à 25 ans y a pas de raisons...), on lui a proposé "screen". Je ne connaissait pas nohup.
Ce n'est pas tout à fait le même usage, même si ça peut se ressembler.
Comme l'a développé Paul Gaborit, nohup permet de détacher une commande, un processus du shell qui l'a lancé pour qu'à la mort du shell la commande si ele dure ou le programme lancé ne meure pas avec lui. Mais une fois détaché, on ne peut plus interagir avec, on peut tout juste aller voir s'il y a une sortie dans le fichier généré par nohup à cet effet.
Screen permet de lancer un «shell virtuel» dans lequel on lance des commandes ou des programmes comme d'habitude mais que l'on peut détacher (comme pour nohup le process ou la commande suit son cours) mais sur lequel on peut se rebrancher. Soit plus tard, soit d'un autre terminal (vt mode texte ou xterm).
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.
Autre point pratique, on peut lancer plusieurs shells dans le même screen et switcher de l'un à l'autre.
-- Sébastien Kirche
Khanh-Dang
Si c'est un truc que l'on lance en tache de fond, et qu'on souhaite oublier jusqu'à ce qu'il ait fini, il faut utiliser nohup.
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).
Si c'est un truc que l'on lance en tache de fond, et
qu'on souhaite oublier jusqu'à ce qu'il ait fini, il faut utiliser
nohup.
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).
Si c'est un truc que l'on lance en tache de fond, et qu'on souhaite oublier jusqu'à ce qu'il ait fini, il faut utiliser nohup.
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).
