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.
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).
Pas forcement, ca va dependre de si ils sont des controlleurs de terminal ou pas ou de comment ils meurent (signal, signal non trappable ou exit normal) et de si les jobs sont en background ou en foreground. Des background jobs peuvent meme se prendre des HUP tous seuls si le shell est un controlleur de terminal et s'ils sont suspendus..
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).
Qu'est-ce que tu entends par "gerent le nohup tout seul en interne". Ils ne font tout simplement rien (ne font pas leur boulot de job control correctement), ils ne detachent rien du tout. Les sorties ne sont pas redirigees, si csh etait un controlleur de terminal, alors ces jobs deviennent orphelin et leur read/write renvoient des EIO s'il essaient d'acceder au terminal, mais ca n'a rien a voir avec le shell.
D'autres enfin (au moins 'zsh' si mes souvenirs sont bons) permettent de choisir le comportement voulu...
Oui, voir l'option "HUP" (on par defaut).
tcsh a la commande interne "hup" qui dit que cette commande devra se prendre un SIGHUP si le shell se termine.
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).
Pas forcement, ca va dependre de si ils sont des controlleurs de
terminal ou pas ou de comment ils meurent (signal, signal non
trappable ou exit normal) et de si les jobs sont en background
ou en foreground. Des background jobs peuvent meme se prendre
des HUP tous seuls si le shell est un controlleur de terminal et
s'ils sont suspendus..
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).
Qu'est-ce que tu entends par "gerent le nohup tout seul en
interne". Ils ne font tout simplement rien (ne font pas leur
boulot de job control correctement), ils ne detachent rien du
tout. Les sorties ne sont pas redirigees, si csh etait un
controlleur de terminal, alors ces jobs deviennent orphelin et
leur read/write renvoient des EIO s'il essaient d'acceder au
terminal, mais ca n'a rien a voir avec le shell.
D'autres enfin (au moins 'zsh' si mes souvenirs sont bons) permettent de
choisir le comportement voulu...
Oui, voir l'option "HUP" (on par defaut).
tcsh a la commande interne "hup" qui dit que cette commande
devra se prendre un SIGHUP si le shell se termine.
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).
Pas forcement, ca va dependre de si ils sont des controlleurs de terminal ou pas ou de comment ils meurent (signal, signal non trappable ou exit normal) et de si les jobs sont en background ou en foreground. Des background jobs peuvent meme se prendre des HUP tous seuls si le shell est un controlleur de terminal et s'ils sont suspendus..
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).
Qu'est-ce que tu entends par "gerent le nohup tout seul en interne". Ils ne font tout simplement rien (ne font pas leur boulot de job control correctement), ils ne detachent rien du tout. Les sorties ne sont pas redirigees, si csh etait un controlleur de terminal, alors ces jobs deviennent orphelin et leur read/write renvoient des EIO s'il essaient d'acceder au terminal, mais ca n'a rien a voir avec le shell.
D'autres enfin (au moins 'zsh' si mes souvenirs sont bons) permettent de choisir le comportement voulu...
Oui, voir l'option "HUP" (on par defaut).
tcsh a la commande interne "hup" qui dit que cette commande devra se prendre un SIGHUP si le shell se termine.
-- Stéphane
Stephane Chazelas
2005-04-9, 00:07(+02), Khanh-Dang:
for i in /toto/titi/*.txt; do perl -pi -e "s/toto/titi/g" $i; done
Là, tu lances un perl par fichier ...
sed -i -e 's/toto/titi/g' /toto/titi/*.txt
(Gnu sed v.4)
Qui ne fait pas la même chose que perl. En effet, l'option '-i' du GNU sed crée un nouveau fichier, donc changement d'inode, et ne conserve pas les permissions d'origine du fichier contrairement à l'option '-i' de perl.
Chez moi, avec GNU sed 4.0.9, l'option -i crée bien un nouvel inode. En revanche, les permissions d'origine sont conservés.
Et mon perl 5.8.5 se comporte de la même manière, à savoir changement d'inode et conservation des permissions.
Ca me semblerait quand même assez risqué qu'un programme manipule un fichier réellement sur place. Que se passerait-il si on interrompt le processus en plein milieu. Il est quand même bon que ce genre d'opérations soient fait de manière atomique (soit tout est fait, soit rien n'est fait).
perl et sed avec "-i" perdent les fichiers en cas de probleme anyway. Ils font (au moins perl) l'equivalent de:
Reutiliser le meme inode n'implique pas forcement que ce soit moins sure, c'est juste qu'on aura plus d'ennuis avec les permissions.
set -C cat fichier > fichier.back && set +C && cmd < fichier.back > fichier
est a peu pres sur et conserve l'inode de fichier.
-- Stéphane
2005-04-9, 00:07(+02), Khanh-Dang:
for i in /toto/titi/*.txt; do perl -pi -e "s/toto/titi/g" $i; done
Là, tu lances un perl par fichier ...
sed -i -e 's/toto/titi/g' /toto/titi/*.txt
(Gnu sed v.4)
Qui ne fait pas la même chose que perl. En effet, l'option '-i' du GNU sed
crée un nouveau fichier, donc changement d'inode, et ne conserve pas les
permissions d'origine du fichier contrairement à l'option '-i' de perl.
Chez moi, avec GNU sed 4.0.9, l'option -i crée bien un nouvel inode. En
revanche, les permissions d'origine sont conservés.
Et mon perl 5.8.5 se comporte de la même manière, à savoir changement
d'inode et conservation des permissions.
Ca me semblerait quand même assez risqué qu'un programme manipule un
fichier réellement sur place. Que se passerait-il si on interrompt le
processus en plein milieu. Il est quand même bon que ce genre
d'opérations soient fait de manière atomique (soit tout est fait, soit
rien n'est fait).
perl et sed avec "-i" perdent les fichiers en cas de probleme
anyway. Ils font (au moins perl) l'equivalent de:
for i in /toto/titi/*.txt; do perl -pi -e "s/toto/titi/g" $i; done
Là, tu lances un perl par fichier ...
sed -i -e 's/toto/titi/g' /toto/titi/*.txt
(Gnu sed v.4)
Qui ne fait pas la même chose que perl. En effet, l'option '-i' du GNU sed crée un nouveau fichier, donc changement d'inode, et ne conserve pas les permissions d'origine du fichier contrairement à l'option '-i' de perl.
Chez moi, avec GNU sed 4.0.9, l'option -i crée bien un nouvel inode. En revanche, les permissions d'origine sont conservés.
Et mon perl 5.8.5 se comporte de la même manière, à savoir changement d'inode et conservation des permissions.
Ca me semblerait quand même assez risqué qu'un programme manipule un fichier réellement sur place. Que se passerait-il si on interrompt le processus en plein milieu. Il est quand même bon que ce genre d'opérations soient fait de manière atomique (soit tout est fait, soit rien n'est fait).
perl et sed avec "-i" perdent les fichiers en cas de probleme anyway. Ils font (au moins perl) l'equivalent de:
Je recommence. Pour détacher un processus d'un terminal, la bonne méthode est de le changer de session, pas d'ignorer les SIGHUP. nohup ignore fait en sorte qu'il ignore les SIGHUP, et ne touche pas à la session. Ergo nohup ne fait pas The Right Thing.
Oui, on est d'accord là dessus, mais...
Sous Linux, il existe une *commande* setsid, qui fait précisément cet appel système avant d'exécuter la suite.
C'est bien ce qu'il me semblait : linux n'est pas The Right Thing. [gimli] ~> uname -s FreeBSD [gimli] ~> which setsid setsid not found
Au moins, nohup est portable... D'ailleurs, je me demande si disown dans zsh ne fait pas un setsid plutôt qu'un masque des signaux.
-- Voilà voilà. Je n'espère pas vous avoir éclairé (j'ai trop d'habitude des news pour ignorer le fait que la plupart des gens sont réfractaires à l'information) mais j'aime bien relire ma prose. -+- TP in GNU : Il n'est pas nécéssaire d'espérer pour entreprendre -+-
Hello Nicolas,
Je recommence. Pour détacher un processus d'un terminal, la bonne méthode
est de le changer de session, pas d'ignorer les SIGHUP. nohup ignore fait en
sorte qu'il ignore les SIGHUP, et ne touche pas à la session. Ergo nohup ne
fait pas The Right Thing.
Oui, on est d'accord là dessus, mais...
Sous Linux, il existe une *commande* setsid, qui fait précisément cet appel
système avant d'exécuter la suite.
C'est bien ce qu'il me semblait : linux n'est pas The Right Thing.
[gimli] ~> uname -s
FreeBSD
[gimli] ~> which setsid
setsid not found
Au moins, nohup est portable... D'ailleurs, je me demande si disown
dans zsh ne fait pas un setsid plutôt qu'un masque des signaux.
--
Voilà voilà. Je n'espère pas vous avoir éclairé (j'ai trop d'habitude
des news pour ignorer le fait que la plupart des gens sont réfractaires
à l'information) mais j'aime bien relire ma prose.
-+- TP in GNU : Il n'est pas nécéssaire d'espérer pour entreprendre -+-
Je recommence. Pour détacher un processus d'un terminal, la bonne méthode est de le changer de session, pas d'ignorer les SIGHUP. nohup ignore fait en sorte qu'il ignore les SIGHUP, et ne touche pas à la session. Ergo nohup ne fait pas The Right Thing.
Oui, on est d'accord là dessus, mais...
Sous Linux, il existe une *commande* setsid, qui fait précisément cet appel système avant d'exécuter la suite.
C'est bien ce qu'il me semblait : linux n'est pas The Right Thing. [gimli] ~> uname -s FreeBSD [gimli] ~> which setsid setsid not found
Au moins, nohup est portable... D'ailleurs, je me demande si disown dans zsh ne fait pas un setsid plutôt qu'un masque des signaux.
-- Voilà voilà. Je n'espère pas vous avoir éclairé (j'ai trop d'habitude des news pour ignorer le fait que la plupart des gens sont réfractaires à l'information) mais j'aime bien relire ma prose. -+- TP in GNU : Il n'est pas nécéssaire d'espérer pour entreprendre -+-
