Génération de plusieurs process depuis une boucle for
14 réponses
faly
Bonjour,
J'ai lancé le script suivant dpuis une émulationvt par telnet et quamd je l'ai interrompu, autant de process que d'itérations on été créés en parallèle. Avez-vous une explication?
Je m'attendait, malgré le ctrl-c à n'avoir qu'un seule find à la fois et non x find en parallèle...
Naturellement, quand j'ai fait un ctrl-c les process fils ont été adoptés par le prox^cess 1.
Merci de vos réponses.
Le script:
for fichier in `cat /tmp/liste_fichiers`
do
find /home/me/rep -name $fichier -exec ls -l {}\; >> /tmp/liste_etendu.txt
done
do find /home/me/rep -name $fichier -exec ls -l {}; >> /tmp/liste_etendu.txt
Il manque des quotes autour de $fichier, il manque l'option -d a ls,
<chipotage> Ne serait-il pas plus judicieux (si l'OP veut examiner des fichiers) d'utiliser l'option "-type f" de find et de laisser le "ls" tel-quel ? </>
do
find /home/me/rep -name $fichier -exec ls -l {}; >> /tmp/liste_etendu.txt
Il manque des quotes autour de $fichier, il manque l'option -d a
ls,
<chipotage>
Ne serait-il pas plus judicieux (si l'OP veut examiner des fichiers)
d'utiliser l'option "-type f" de find et de laisser le "ls" tel-quel ?
</>
do find /home/me/rep -name $fichier -exec ls -l {}; >> /tmp/liste_etendu.txt
Il manque des quotes autour de $fichier, il manque l'option -d a ls,
<chipotage> Ne serait-il pas plus judicieux (si l'OP veut examiner des fichiers) d'utiliser l'option "-type f" de find et de laisser le "ls" tel-quel ? </>
Pour eviter d'avoir a rescanner le repertoire pour chaque fichier, tu peux faire:
shift "$#" while IFS= read -r fichier; do set -- "$@" -o -name "$fichier" done < /tmp/liste_fichiers || exit shift || exit find /home/me/resp ( "$@" ) -exec ls -ld {} + > /tmp/liste_etendu.txt
Le "+" a la place de ";" evite de lancer un "ls" par fichier.
malheureusement, + n'est pas portable...
PS : de mémoire, IFS= read ne marche pas avec tous les shell. ce qui impose qqc comme :
oIFS=$IFS IFS= while read ...; do IFS=$oIFS ... IFS= done
ça complique... et il ne faut pas oublier d'IFS= lors d'un continue : )
à ce propos, dans le cas présent, l'IFS ne sert à rien puisque tu n 'as qu'une variable dans le read !
PS : dernier bug bash trouvé, read != read REPLY, mais je ne sais plu s dans quelle condition ! je reviendrai la dessus après mes congés...
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Stephane CHAZELAS
2008-07-11, 22:24(+02), Cyrille Lefevre:
Stephane CHAZELAS a écrit :
Il te faut specifier IFS et disabler le globbing:
s/disabler/désactiver/ :)
Pour eviter d'avoir a rescanner le repertoire pour chaque fichier, tu peux faire:
shift "$#" while IFS= read -r fichier; do set -- "$@" -o -name "$fichier" done < /tmp/liste_fichiers || exit shift || exit find /home/me/resp ( "$@" ) -exec ls -ld {} + > /tmp/liste_etendu.txt
Le "+" a la place de ";" evite de lancer un "ls" par fichier.
malheureusement, + n'est pas portable...
Le + est POSIX donc standard. Apres, ca depend ce que tu appelles portable. En l'occurrence, une fois n'est pas coutume, c'etait GNU qui etait a la traine car le GNU find ne l'a rajouté que relativement recemment.
PS : de mémoire, IFS= read ne marche pas avec tous les shell. ce qui impose qqc comme :
Si, par contre pour certains shells, IFS reste a sa valeur apres que "read" ait retourné, mais ce n'est pas tres grave puisque pour ces memes shells (le Bourne shell en l'occurrence), rediriger une boucle lance la boucle dans un subshell.
Par contre "-r" n'est pas Bourne. Mais ou est l'interet d'ecrire pour Bourne de nos jours quand tous les Unix ont un sh standard qui l'a remplacé ?
oIFS=$IFS IFS > while read ...; do IFS=$oIFS ... IFS > done
ça complique... et il ne faut pas oublier d'IFS= lors d'un continue :)
IFS=$oIFS n'est pas correct si IFS etait initialement unset.
à ce propos, dans le cas présent, l'IFS ne sert à rien puisque tu n'as qu'une variable dans le read !
Si. Il faut enlever les espaces sans quoi ils sont enlevés du debut et de la fin de la ligne.
echo ' xxx ' | read var
stocke "xxx" dans $var
PS : dernier bug bash trouvé, read != read REPLY, mais je ne sais plus dans quelle condition ! je reviendrai la dessus après mes congés...
read sans variable n'est pas POSIX et le comportement varie.
Avec bash:
echo ' xxx ' | read
stocke ' xxx ' dans $REPLY pour bash, xxx pour ksh ou zsh et donne une erreur dans d'autres shells.
Ce n'est pas un bug de bash, c'est une feature documentee.
-- Stéphane
2008-07-11, 22:24(+02), Cyrille Lefevre:
Stephane CHAZELAS a écrit :
Il te faut specifier IFS et disabler le globbing:
s/disabler/désactiver/ :)
Pour eviter d'avoir a rescanner le repertoire pour chaque
fichier, tu peux faire:
shift "$#"
while IFS= read -r fichier; do
set -- "$@" -o -name "$fichier"
done < /tmp/liste_fichiers || exit
shift || exit
find /home/me/resp ( "$@" ) -exec ls -ld {} + > /tmp/liste_etendu.txt
Le "+" a la place de ";" evite de lancer un "ls" par fichier.
malheureusement, + n'est pas portable...
Le + est POSIX donc standard. Apres, ca depend ce que tu
appelles portable. En l'occurrence, une fois n'est pas coutume,
c'etait GNU qui etait a la traine car le GNU find ne l'a rajouté
que relativement recemment.
PS : de mémoire, IFS= read ne marche pas avec tous les shell.
ce qui impose qqc comme :
Si, par contre pour certains shells, IFS reste a sa valeur apres
que "read" ait retourné, mais ce n'est pas tres grave puisque
pour ces memes shells (le Bourne shell en l'occurrence),
rediriger une boucle lance la boucle dans un subshell.
Par contre "-r" n'est pas Bourne. Mais ou est l'interet d'ecrire
pour Bourne de nos jours quand tous les Unix ont un sh standard
qui l'a remplacé ?
oIFS=$IFS
IFS > while read ...; do
IFS=$oIFS
...
IFS > done
ça complique... et il ne faut pas oublier d'IFS= lors d'un continue :)
IFS=$oIFS n'est pas correct si IFS etait initialement unset.
à ce propos, dans le cas présent, l'IFS ne sert à rien puisque tu n'as
qu'une variable dans le read !
Si. Il faut enlever les espaces sans quoi ils sont enlevés du
debut et de la fin de la ligne.
echo ' xxx ' | read var
stocke "xxx" dans $var
PS : dernier bug bash trouvé, read != read REPLY, mais je ne sais plus
dans quelle condition ! je reviendrai la dessus après mes congés...
read sans variable n'est pas POSIX et le comportement varie.
Avec bash:
echo ' xxx ' | read
stocke ' xxx ' dans $REPLY pour bash, xxx pour ksh ou zsh et
donne une erreur dans d'autres shells.
Ce n'est pas un bug de bash, c'est une feature documentee.
Pour eviter d'avoir a rescanner le repertoire pour chaque fichier, tu peux faire:
shift "$#" while IFS= read -r fichier; do set -- "$@" -o -name "$fichier" done < /tmp/liste_fichiers || exit shift || exit find /home/me/resp ( "$@" ) -exec ls -ld {} + > /tmp/liste_etendu.txt
Le "+" a la place de ";" evite de lancer un "ls" par fichier.
malheureusement, + n'est pas portable...
Le + est POSIX donc standard. Apres, ca depend ce que tu appelles portable. En l'occurrence, une fois n'est pas coutume, c'etait GNU qui etait a la traine car le GNU find ne l'a rajouté que relativement recemment.
PS : de mémoire, IFS= read ne marche pas avec tous les shell. ce qui impose qqc comme :
Si, par contre pour certains shells, IFS reste a sa valeur apres que "read" ait retourné, mais ce n'est pas tres grave puisque pour ces memes shells (le Bourne shell en l'occurrence), rediriger une boucle lance la boucle dans un subshell.
Par contre "-r" n'est pas Bourne. Mais ou est l'interet d'ecrire pour Bourne de nos jours quand tous les Unix ont un sh standard qui l'a remplacé ?
oIFS=$IFS IFS > while read ...; do IFS=$oIFS ... IFS > done
ça complique... et il ne faut pas oublier d'IFS= lors d'un continue :)
IFS=$oIFS n'est pas correct si IFS etait initialement unset.
à ce propos, dans le cas présent, l'IFS ne sert à rien puisque tu n'as qu'une variable dans le read !
Si. Il faut enlever les espaces sans quoi ils sont enlevés du debut et de la fin de la ligne.
echo ' xxx ' | read var
stocke "xxx" dans $var
PS : dernier bug bash trouvé, read != read REPLY, mais je ne sais plus dans quelle condition ! je reviendrai la dessus après mes congés...
read sans variable n'est pas POSIX et le comportement varie.
Avec bash:
echo ' xxx ' | read
stocke ' xxx ' dans $REPLY pour bash, xxx pour ksh ou zsh et donne une erreur dans d'autres shells.
Ce n'est pas un bug de bash, c'est une feature documentee.
-- Stéphane
Stephane CHAZELAS
2008-07-11, 20:12(+02), Thierry B.:
--{ Stephane CHAZELAS a plopé ceci: }--
do find /home/me/rep -name $fichier -exec ls -l {}; >> /tmp/liste_etendu.txt
Il manque des quotes autour de $fichier, il manque l'option -d a ls,
<chipotage> Ne serait-il pas plus judicieux (si l'OP veut examiner des fichiers) d'utiliser l'option "-type f" de find et de laisser le "ls" tel-quel ? </>
[...]
Ben non, -type f est pour les fichiers reguliers, il y a plein d'autres types de fichier: les fifo, les repertoires, les devices, les symlinks et j'en passe.
Il se trouve que ls se comporte differemment pour les fichiers de type repertoire que pour les autres types de fichiers, a moins d'utiliser l'option -d.
ls sans "-d", c'est justement quand on veut lister le contenu d'un repertoire. Si on veut lister les attributs d'un fichier particulier, c'est ls -d, qu'on peut ommettre si on sait que les fichiers a lister en question ne sont pas des repertoires, mais c'est une mauvaise habitude a prendre.
-- Stéphane
2008-07-11, 20:12(+02), Thierry B.:
--{ Stephane CHAZELAS a plopé ceci: }--
do
find /home/me/rep -name $fichier -exec ls -l {}; >> /tmp/liste_etendu.txt
Il manque des quotes autour de $fichier, il manque l'option -d a
ls,
<chipotage>
Ne serait-il pas plus judicieux (si l'OP veut examiner des fichiers)
d'utiliser l'option "-type f" de find et de laisser le "ls" tel-quel ?
</>
[...]
Ben non, -type f est pour les fichiers reguliers, il y a plein
d'autres types de fichier: les fifo, les repertoires, les
devices, les symlinks et j'en passe.
Il se trouve que ls se comporte differemment pour les fichiers
de type repertoire que pour les autres types de fichiers, a
moins d'utiliser l'option -d.
ls sans "-d", c'est justement quand on veut lister le contenu
d'un repertoire. Si on veut lister les attributs d'un fichier
particulier, c'est ls -d, qu'on peut ommettre si on sait que les
fichiers a lister en question ne sont pas des repertoires, mais
c'est une mauvaise habitude a prendre.
do find /home/me/rep -name $fichier -exec ls -l {}; >> /tmp/liste_etendu.txt
Il manque des quotes autour de $fichier, il manque l'option -d a ls,
<chipotage> Ne serait-il pas plus judicieux (si l'OP veut examiner des fichiers) d'utiliser l'option "-type f" de find et de laisser le "ls" tel-quel ? </>
[...]
Ben non, -type f est pour les fichiers reguliers, il y a plein d'autres types de fichier: les fifo, les repertoires, les devices, les symlinks et j'en passe.
Il se trouve que ls se comporte differemment pour les fichiers de type repertoire que pour les autres types de fichiers, a moins d'utiliser l'option -d.
ls sans "-d", c'est justement quand on veut lister le contenu d'un repertoire. Si on veut lister les attributs d'un fichier particulier, c'est ls -d, qu'on peut ommettre si on sait que les fichiers a lister en question ne sont pas des repertoires, mais c'est une mauvaise habitude a prendre.
