Version imprimable
Bonjour,
Je dois exécuter plusieurs sed et des un cat >> via une boucle sur 2 000 fichiers.
Cependant au bout de 800 fichiers la boucle s'arrête :/ : les 700 premiers fichiers sont bien traités mais les 100 suivants sont en fait 100 fichiers parmi les 1 300 autres.
Est ce que vous savez pourquoi ?? Est-ce que les scripts on un temps limité ?
Il m'arrive aussi des fois le message "Segmentation fault (core dumped)" sur un script très long.
Cordialement :)
Bonjour
Sans que tu nous montres le script en question... :?Citation:
Envoyé par Amaury77
Non. Maintenant on peut imaginer que le script, à force de créer des fichiers (peut-être dans "/tmp") finit par saturer le filesystem...Citation:
Envoyé par Amaury77
Bonjour :coucou:
N'est-ce pas une boucle en forme de for fichier in $(ls *), et qui s'est fait prendre par les limitations ? On déplore ce genre de mauvais code sur le forum constamment. Mais les internautes persistent car "ça marche".
Il faut considérer un fichier, avec 1 ligne par cible.
Oui tout à fait c'est une simple boucle for avec un ls -v, je ne peux pas envoyer les fichiers car le messages serait trop long, est ce que tu aurait un exemple de structure avec : un fichier, avec 1 ligne par cible.
Sachant qu'en bash, le fichier.txt peut être remplacé par une substitution de processus <( ).Code:
2
3
4
C'est vrai que ce n'est pas super propre (si le dossier contient des sous-dossiers alors le ls * va exploser en étoile et je suis étonné de ne pas encore avoir vu N_BaH arriver en piqué diagonal venir expliquer qu'on ne met pas de "ls" dans un script) mais je n'ai pas réussi à reproduire cette limitation.Citation:
Envoyé par Flodelarab
J'ai en effet créé 50000 fichiers for f in $(seq 50000); do touch "fic_$f"; done j'ai parfaitement pu les récupérer => for f in $(ls); do echo "$f"; done |wc => 50000
Ton script est si long que ça ??? 8O Généralement ça traduit une mauvaise conception.Citation:
Envoyé par Amaury77
Mais même avec un script super long, tu n'es pas capable de poster juste la structure de boucle avec un traitement minimal, exemple
Enfin bon, vu que tu as dit ce que tu faisais, ça ne doit pas être bien différent de ce que je viens d'écrire.Code:
2
3
Donc comme un certain modérateur te le dira s'il vient à passer par là, on ne fait pas de "ls" dans un script. Parce que "ls" interprète certains caractères et qu'un fichier nommé par exemple mon'$'\n''fait'$'\n''chier ne pourra pas être pris en compte (c'est lui qui m'a défié de traiter ce fichier via "ls" et je n'y suis toujours pas arrivé).
Tu veux traiter des fichiers dans un dossier: for f in *; do echo "[$f]"; done.
Tu veux traiter des fichiers dans une arborescence: while read f; do echo "[$f]"; done < <(find dossier_racine_arborescence -type f)
en général, le problème n'est pas le nombre d'arguments, mais le nombre de caractères d'une ligne de commande (ARG_MAX), mais il me semble me souvenir que le message serait différent, et explicite.
le segfault peut venir d'un fichier non trouvé, et de données non reçues...-print0 sinon la boucle ne lira que mon$'\n', et pas mon$'\n'fait$'\n'chier. :aie:Code:while read -d ''; do echo "$REPLY"; done < <(find "$chemin" -type f -print0 | sort -zV)
C'est cela, mais les derniers fichiers ne sont pas bien traité voir sauter car issu d'un ls , si j'utilise une boucle while comme celaCitation:
Envoyé par Sve@r
je devrais faire une boucle de boucles pour traiter tous les fichiers ? :?Citation:
Envoyé par Flodelarab
Dans mon exemple for f in *; do echo "[$f]"; done il n'y a pas de "ls" !!!Citation:
Envoyé par Amaury77
Tu n'as absolument rien bité de la commande de FlodelarabCitation:
Envoyé par Amaury77
Son exemple explique comment lire un fichier nommé "fichier.txt" ligne par ligne. Et cet exemple plus généraliste while read ligne; do echo "macommande $ligne" done < <(commande Unix retournant des lignes) permet de lire une commande Unix retournant des lignes ligne par ligne.
Ce type de syntaxe s'appuie sur le fait qu'un read lit tout jusqu'au <return> tandis qu'une ligne affichée par une commande Unix se termine par <return>.
Donc le "read" lit une ligne entière en provenance du fichier (première syntaxe) ou de ce que la commande affiche (seconde syntaxe) et le "while" fait ensuite boucler pour tout lire ligne par ligne.
bonjour
si tu désires véritablement de l'aide, il faut nous donner le code (et types des fichiers) sinon il nous est impossible de deviner ! et donc d'apporter une véritable aide.
L'erreur peut-être dans ta boucle mais aussi dans ton traitement dans cette boucle (sed et cat ?)
Peut-être que tu as des espaces (ou autre) dans les noms de fichier qu'au bout de 800 fichiers ?
Peut-être que le contenu des fichiers est mauvais au bout de 800 fichiers ?
Peut-être que ... (fois 100)
Mais vu ta dernière réponse, apparemment, tu n'es pas à l'aise avec bash donc c'est plutôt une erreur de codage
Une première chose est de lancer le script en mode debug ;) (avec -X )
fichiers dans dossier
(il y a 20 lignes par fichiers)Code:
2
3
4
5
6
7
8
9
10
11
12
13
14oligo-rec-dyn.0.wo_frame_20.a1 oligo-rec-dyn.0.wo_frame_40.a1 oligo-rec-dyn.0.wo_frame_60.a1 oligo-rec-dyn.0.wo_frame_80.a1 oligo-rec-dyn.0.wo_frame_100.a1 ... 100 fichiers ... ... oligo-rec-dyn.900.w_frame_20.a1 oligo-rec-dyn.900.w_frame_40.a1 oligo-rec-dyn.900.w_frame_60.a1 oligo-rec-dyn.900.w_frame_80.a1 oligo-rec-dyn.900.w_frame_100.a1
Je voudrais qu'ils soient traités dans l'ordre
J'ai toutes les lignes pour ceux-là (les premiers) : oligo-rec-dyn.0.wo_frame_20.a1, oligo-rec-dyn.0.wo_frame_40.a1 ,oligo-rec-dyn.0.wo_frame_60.a1 ,oligo-rec-dyn.0.wo_frame_80.a1 , oligo-rec-dyn.0.wo_frame_100.a1 , oligo-rec-dyn.0.w_frame_20.a1 , oligo-rec-dyn.0.w_frame_40.a1 et encore des fois il en manque une.Code:
2
3
mais pour ceux-là (les derniers): oligo-rec-dyn.900.w_frame_80.a1, oligo-rec-dyn.900.w_frame_100.a1, j'ai que 2 lignes
Là je me rends compte qu'il manque des lignes sur la fin, d'où mon impression que le script "s’arrête" ou qu'il "s'épuise"
une version sûre :Code:$ find "$src" -maxdepth 1 -type f -name 'oligo-*.a1' -print0 | sort -zV | xargs -I{} -0 cat {} >"$dst/ouptut.fic"
Beaucoup de choses à répondre :
- D'abord, pour savoir si un élève est manquant, on compte les élèves. On ne regarde pas seulement si les cancres sont là. Il faut compter tes fichiers, pas regarder la fin de liste.
- Pour compter, souvent, on utilise ceci :
wc - l fichier.txt
sed -n '$=' fichier.txt
- Il y a au moins 2 ordres naturels : l'ordre numérique et l'ordre lexicographique.
- 10.txt est devant 100.txt dans l'ordre numérique.
- 100.txt est devant 10.txt dans l'ordre lexicographique (alphabétique, si tu préfères)
Ton "dernier" fichier 100 est probablement perdu à côté du fichier 10.- On n'utilise pas ls dans un script. On remplace par find ou stat.
Dans quel ordre exactement ? Parce que si c'est leur ordre nominatif, alors for f in *; do echo "[$f]"; done (déjà mentionné deux fois) le fera parfaitement.Citation:
Envoyé par Amaury77
Et si c'est un autre ordre, alors imaginons que la commande "xxx" ressorte tous les fichiers dans cet ordre là, ce sera while read f; do echo "[$f]"; done <( (xxx) ("xxx" à adapter ensuite à partir de la vraie commande qui renvoie les fichiers dans l'ordre qui te convient mais en excluant "ls").
Evidemment !!!Citation:
Envoyé par Amaury77
Donc les commandes Unix (ex "cat") peuvent bien évidemment recevoir des éléments en paramètre (ex cat titi toto tata) mais la mémoire d'un programme n'est pas illimitée. Parce que ces arguments, le programme il doit d'abord les stocker pour les traiter. Tu n'es jamais tombé sur un message style cmd: arg_list too long parce que tu avais tapé cmd * ("cmd" à adapter en fonction de vraies commandes que tu peux être amené à utiliser) ?
Et là tu envoies allègrement à "cat" tes 2000 fichiers. Remarque 2000 c'est pas exagéré et normalement ça devrait le faire mais bon, visiblement ça ne le fait pas et même si ça le faisait pour 2000, ce n'est pas pérenne (le jour où ça passera à 10000, 100000...)
Donc il faut boucler sur chaque fichier et traiter chaque fichier => for f in oligo*; do cat "$f"; done >"all_oligo.a1".
Et c'est parce que ce type de travail, que de traiter tous les fichiers via une action, était très souvent nécessaire que les programmeurs Linux ont créé "xargs" mentionnée par N_BaH dont le rôle est de découper une grosse liste input en n petites listes output afin de pouvoir faire traiter ces petites listes par des commandes de son choix pour lesquelles ces petites listes seront acceptables en terme de taille => find . -type f -name "oligo*" -print0 | xargs -0 -I {} cat {} >"all_oligo.a1".
Ordre numériqueCitation:
Envoyé par Sve@r
C'est un peu ce que Flodelarab pensait quand il a parlé d'ordre numérique par rapport à l'ordre alphabétique.Citation:
Envoyé par Amaury77
C'est bien vu d'avoir pensé au "ls -v" (mais les fichiers temporaires étaient inutiles, tu aurais dû écrire cat $(ls -v oligo*) >"all_oligo.a1"). Sauf qu'on n'utilise pas de "ls" dans les scripts (ce que tu ne savais pas).
Donc voir la solution de N_BaH qui récupère tous tes fichiers, les trie numériquement, puis appelle "xargs" qui elle se charge de faire la boucle sur le flot qu'elle reçoit (la liste triée) pour pouvoir les faire traiter par "cat" un à un.
Ce qui donne find . -maxdepth 1 -type f -name 'oligo-*.a1' -print0 | sort -zV | xargs -0 -I{} cat {} >"all_oligo.a1".
La même version plus détaillée
Code:
2
3
Merci beaucoup !! :D