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.
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) -- Jacques L'helgoualc'h
Khanh-Dang
for i in /toto/titi/*.txt; do perl -pi -e "s/toto/titi/g" $i; done
Là, c'est quand même de l'abus total d'écrire ça.
Il est plus important de mettre des guillemets autour de $i que de s/toto/titi/g. Et puis un shell peut parfaitement remplir le rôle de Perl ici. Et dans le pire des cas, si tu tiens vraiment à utiliser une commande externe, autant le faire avec sed ici, qui semble plus approprié.
for i in /toto/titi/*.txt; do perl -pi -e "s/toto/titi/g" $i; done
Là, c'est quand même de l'abus total d'écrire ça.
Il est plus important de mettre des guillemets autour de $i que de
s/toto/titi/g. Et puis un shell peut parfaitement remplir le rôle de
Perl ici. Et dans le pire des cas, si tu tiens vraiment à utiliser une
commande externe, autant le faire avec sed ici, qui semble plus
approprié.
for i in /toto/titi/*.txt; do perl -pi -e "s/toto/titi/g" $i; done
Là, c'est quand même de l'abus total d'écrire ça.
Il est plus important de mettre des guillemets autour de $i que de s/toto/titi/g. Et puis un shell peut parfaitement remplir le rôle de Perl ici. Et dans le pire des cas, si tu tiens vraiment à utiliser une commande externe, autant le faire avec sed ici, qui semble plus approprié.
TiChou
Dans le message <news:slrnd5drmd.vaj.lhh+, *Jacques L'helgoualc'h* tapota sur f.c.o.unix :
[...]
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.
-- TiChou
Dans le message <news:slrnd5drmd.vaj.lhh+no_spam@ulysse.maison>,
*Jacques L'helgoualc'h* tapota sur f.c.o.unix :
[...]
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.
Dans le message <news:slrnd5drmd.vaj.lhh+, *Jacques L'helgoualc'h* tapota sur f.c.o.unix :
[...]
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.
-- TiChou
Nicolas George
Stephane Dupille wrote in message :
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.
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.
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.
Sous Linux, il existe une *commande* setsid, qui fait précisément cet appel système avant d'exécuter la suite.
Stephane Dupille wrote in message
<m2y8btoix9.fsf@gimli.dustnet.teaser.fr>:
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.
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.
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.
Sous Linux, il existe une *commande* setsid, qui fait précisément cet appel
système avant d'exécuter la suite.
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.
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.
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.
Sous Linux, il existe une *commande* setsid, qui fait précisément cet appel système avant d'exécuter la suite.
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).
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).
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).
Jacques L'helgoualc'h
Le 08-04-2005, TiChou a écrit :
Dans le message <news:slrnd5drmd.vaj.lhh+, *Jacques L'helgoualc'h* tapota sur f.c.o.unix : [...]
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,
OK.
et ne conserve pas les permissions d'origine du fichier contrairement à l'option '-i' de perl.
,---- /usr/share/doc/sed/NEWS.gz [...] | Sed 4.1.1 | | * preserve permissions of in-place edited files | `----
-- Jacques L'helgoualc'h
Le 08-04-2005, TiChou <gro.uohcit@uohcit> a écrit :
Dans le message <news:slrnd5drmd.vaj.lhh+no_spam@ulysse.maison>,
*Jacques L'helgoualc'h* tapota sur f.c.o.unix :
[...]
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,
OK.
et ne conserve pas les permissions d'origine du fichier contrairement
à l'option '-i' de perl.
,---- /usr/share/doc/sed/NEWS.gz
[...]
| Sed 4.1.1
|
| * preserve permissions of in-place edited files
|
`----
Dans le message <news:slrnd5e0hp.gp.lhh+, *Jacques L'helgoualc'h* tapota sur f.c.o.unix :
,---- /usr/share/doc/sed/NEWS.gz [...] | Sed 4.1.1 | | * preserve permissions of in-place edited files | `----
Ah merci de l'information ! C'est assez récent comme changement et je n'ai encore aucune de mes machines qui utilisent une version 4.1.x de GNU sed.
-- TiChou
TiChou
Dans le message <news:425700a4$0$1244$, *Khanh-Dang* tapota sur f.c.o.unix :
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.
pegase tmp # ls -li test 228551 -rw-r----- 1 tichou users 7 Apr 9 00:37 test ^^^^^^ ^^^^^ pegase tmp # sed --version GNU sed version 4.0.9 pegase tmp # sed -i -e 's/a/b/' test pegase tmp # ls -li test 228550 -rw-r----- 1 root root 7 Apr 9 00:42 test ^^^^ ^^^^
Les permissions ont changé.
Et mon perl 5.8.5 se comporte de la même manière, à savoir changement d'inode
Les anciennes versions de perl n'avait pas se comportement et j'en étais resté là.
Ca me semblerait quand même assez risqué qu'un programme manipule un fichier réellement sur place.
Non, ça peut être utile quand on a besoin de manipuler des fichiers déjà ouvert, par exemple des fichiers de log.
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).
C'est pourquoi il est utile de conserver une copie du fichier que l'on modifie en donnant comme paramètre à l'option '-i' un suffxe :
$ perl -i~ -p -e 's///' fichier
-- TiChou
Dans le message <news:425700a4$0$1244$8fcfb975@news.wanadoo.fr>,
*Khanh-Dang* tapota sur f.c.o.unix :
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.
pegase tmp # ls -li test
228551 -rw-r----- 1 tichou users 7 Apr 9 00:37 test
^^^^^^ ^^^^^
pegase tmp # sed --version
GNU sed version 4.0.9
pegase tmp # sed -i -e 's/a/b/' test
pegase tmp # ls -li test
228550 -rw-r----- 1 root root 7 Apr 9 00:42 test
^^^^ ^^^^
Les permissions ont changé.
Et mon perl 5.8.5 se comporte de la même manière, à savoir changement
d'inode
Les anciennes versions de perl n'avait pas se comportement et j'en étais
resté là.
Ca me semblerait quand même assez risqué qu'un programme manipule un
fichier réellement sur place.
Non, ça peut être utile quand on a besoin de manipuler des fichiers déjà
ouvert, par exemple des fichiers de log.
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).
C'est pourquoi il est utile de conserver une copie du fichier que l'on
modifie en donnant comme paramètre à l'option '-i' un suffxe :
Dans le message <news:425700a4$0$1244$, *Khanh-Dang* tapota sur f.c.o.unix :
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.
pegase tmp # ls -li test 228551 -rw-r----- 1 tichou users 7 Apr 9 00:37 test ^^^^^^ ^^^^^ pegase tmp # sed --version GNU sed version 4.0.9 pegase tmp # sed -i -e 's/a/b/' test pegase tmp # ls -li test 228550 -rw-r----- 1 root root 7 Apr 9 00:42 test ^^^^ ^^^^
Les permissions ont changé.
Et mon perl 5.8.5 se comporte de la même manière, à savoir changement d'inode
Les anciennes versions de perl n'avait pas se comportement et j'en étais resté là.
Ca me semblerait quand même assez risqué qu'un programme manipule un fichier réellement sur place.
Non, ça peut être utile quand on a besoin de manipuler des fichiers déjà ouvert, par exemple des fichiers de log.
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).
C'est pourquoi il est utile de conserver une copie du fichier que l'on modifie en donnant comme paramètre à l'option '-i' un suffxe :
$ perl -i~ -p -e 's///' fichier
-- TiChou
Jacques L'helgoualc'h
Le 08-04-2005, TiChou a écrit :
Dans le message <news:slrnd5e0hp.gp.lhh+, *Jacques L'helgoualc'h* tapota sur f.c.o.unix :
Sed 4.1.1 * preserve permissions of in-place edited files
Ah merci de l'information !
merci d'avoir attiré mon attention là-dessus ... j'ai quelques permissions à rectifier.
C'est assez récent comme changement et je n'ai encore aucune de mes machines qui utilisent une version 4.1.x de GNU sed.
La version 4.1.1 date du 30.6.2004, et la 4.1.4 du 28.1.2005 ; évidemment, la debian stable est un peu à la traîne :/ -- Jacques L'helgoualc'h
Le 08-04-2005, TiChou <gro.uohcit@uohcit> a écrit :
Dans le message <news:slrnd5e0hp.gp.lhh+no_spam@ulysse.maison>,
*Jacques L'helgoualc'h* tapota sur f.c.o.unix :
Sed 4.1.1
* preserve permissions of in-place edited files
Ah merci de l'information !
merci d'avoir attiré mon attention là-dessus ... j'ai quelques
permissions à rectifier.
C'est assez récent comme changement et je n'ai encore aucune de mes
machines qui utilisent une version 4.1.x de GNU sed.
La version 4.1.1 date du 30.6.2004, et la 4.1.4 du 28.1.2005 ;
évidemment, la debian stable est un peu à la traîne :/
--
Jacques L'helgoualc'h
Dans le message <news:slrnd5e0hp.gp.lhh+, *Jacques L'helgoualc'h* tapota sur f.c.o.unix :
Sed 4.1.1 * preserve permissions of in-place edited files
Ah merci de l'information !
merci d'avoir attiré mon attention là-dessus ... j'ai quelques permissions à rectifier.
C'est assez récent comme changement et je n'ai encore aucune de mes machines qui utilisent une version 4.1.x de GNU sed.
La version 4.1.1 date du 30.6.2004, et la 4.1.4 du 28.1.2005 ; évidemment, la debian stable est un peu à la traîne :/ -- Jacques L'helgoualc'h
Jacques L'helgoualc'h
Le 08-04-2005, TiChou a écrit :
Dans le message <news:425700a4$0$1244$, *Khanh-Dang* tapota sur f.c.o.unix : [...]
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.
pegase tmp # ls -li test 228551 -rw-r----- 1 tichou users 7 Apr 9 00:37 test ^^^^^^ ^^^^^ pegase tmp # sed --version GNU sed version 4.0.9 pegase tmp # sed -i -e 's/a/b/' test pegase tmp # ls -li test 228550 -rw-r----- 1 root root 7 Apr 9 00:42 test ^^^^ ^^^^
Les permissions ont changé.
Plutôt le propriétaire, en fait ; là aussi, une mise à jour peut être utile.
,---- | Sed 4.1 | [...] | * -i option tries to set the owner and group to the same as the input file `---- -- Jacques L'helgoualc'h
Le 08-04-2005, TiChou <gro.uohcit@uohcit> a écrit :
Dans le message <news:425700a4$0$1244$8fcfb975@news.wanadoo.fr>,
*Khanh-Dang* tapota sur f.c.o.unix :
[...]
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.
pegase tmp # ls -li test
228551 -rw-r----- 1 tichou users 7 Apr 9 00:37 test
^^^^^^ ^^^^^
pegase tmp # sed --version
GNU sed version 4.0.9
pegase tmp # sed -i -e 's/a/b/' test
pegase tmp # ls -li test
228550 -rw-r----- 1 root root 7 Apr 9 00:42 test
^^^^ ^^^^
Les permissions ont changé.
Plutôt le propriétaire, en fait ; là aussi, une mise à jour peut être utile.
,----
| Sed 4.1
| [...]
| * -i option tries to set the owner and group to the same as the input file
`----
--
Jacques L'helgoualc'h
Dans le message <news:425700a4$0$1244$, *Khanh-Dang* tapota sur f.c.o.unix : [...]
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.
pegase tmp # ls -li test 228551 -rw-r----- 1 tichou users 7 Apr 9 00:37 test ^^^^^^ ^^^^^ pegase tmp # sed --version GNU sed version 4.0.9 pegase tmp # sed -i -e 's/a/b/' test pegase tmp # ls -li test 228550 -rw-r----- 1 root root 7 Apr 9 00:42 test ^^^^ ^^^^
Les permissions ont changé.
Plutôt le propriétaire, en fait ; là aussi, une mise à jour peut être utile.
,---- | Sed 4.1 | [...] | * -i option tries to set the owner and group to the same as the input file `---- -- Jacques L'helgoualc'h
