Comment exécuter sed sur plus de 10 millions de fichiers dans un répertoire?

J'ai un répertoire contenant 10144911 fichiers. Jusqu'à présent, j'ai essayé ce qui suit:

• for f in ls; do sed -i -e 's/blah/blee/g' $f; done

J'ai cassé ma coquille, lsc'est dans un tilda mais je ne sais pas comment en faire un.

• ls | xargs -0 sed -i -e 's/blah/blee/g'

Trop d'arguments pour sed

• find . -name "*.txt" -exec sed -i -e 's/blah/blee/g' {} \;

Impossible de bifurquer plus de mémoire

Avez-vous d'autres idées sur la façon de créer cette sorte de commande? Les fichiers n'ont pas besoin de communiquer entre eux. ls | wc -lsemble fonctionner (très lentement) donc ça doit être possible.

Essayez ceci:

find -name '*.txt' -print0 | xargs -0 -I {} -P 0 sed -i -e 's/blah/blee/g' {}

Il ne fournira qu'un seul nom de fichier à chaque invocation de sed. Cela résoudra le problème «trop d'arguments pour sed». L' -Poption doit permettre à plusieurs processus d'être bifurqués en même temps. Si 0 ne fonctionne pas (il est censé en exécuter autant que possible), essayez d'autres nombres (10? 100? Le nombre de cœurs que vous avez?) Pour limiter le nombre.

J'ai testé cette méthode (et toutes les autres) sur 10 millions de fichiers (vides), nommés "hello 00000001" à "hello 10000000" (14 octets par nom).

MISE À JOUR: J'ai maintenant inclus une exécution quad-core sur la 'find |xargs'méthode (toujours sans 'sed'; juste echo> / dev / null) ..

# Step 1. Build an array for 10 million files
#   * RAM usage approx:  1.5 GiB 
#   * Elapsed Time:  2 min 29 sec 
  names=( hello\ * )

# Step 2. Process the array.
#   * Elapsed Time:  7 min 43 sec
  for (( ix=0, cnt=${#names[@]} ; ix<$cnt; ix++ )) ; do echo "${names[ix]}" >/dev/null ; done  

Voici un résumé de la façon dont les réponses fournies se sont comportées lorsqu'elles ont été comparées aux données de test mentionnées ci-dessus. Ces résultats ne concernent que les frais généraux de base; c'est-à-dire que «sed» n'a pas été appelé. Le processus sed sera certainement le plus long, mais j'ai pensé qu'il serait intéressant de voir comment les méthodes nues se comparaient.

La 'find |xargs'méthode de Dennis , utilisant un seul cœur, a pris * 4 heures 21 minutes ** de plus que la bash arrayméthode lors d'une analyse no sed... Cependant, l'avantage multicœur offert par 'find' devrait l'emporter sur les différences de temps indiquées lorsque sed est demandé. traitement des fichiers ...

           | Time    | RAM GiB | Per loop action(s). / The command line. / Notes
-----------+---------+---------+----------------------------------------------------- 
Dennis     | 271 min | 1.7 GiB | * echo FILENAME >/dev/null
Williamson   cores: 1x2.66 MHz | $ time find -name 'hello *' -print0 | xargs -0 -I {} echo >/dev/null {}
                               | Note: I'm very surprised at how long this took to run the 10 million file gauntlet
                               |       It started processing almost immediately (because of xargs I suppose),  
                               |       but it runs **significantly slower** than the only other working answer  
                               |       (again, probably because of xargs) , but if the multi-core feature works  
                               |       and I would think that it does, then it could make up the defecit in a 'sed' run.   
           |  76 min | 1.7 GiB | * echo FILENAME >/dev/null
             cores: 4x2.66 MHz | $ time find -name 'hello *' -print0 | xargs -0 -I {} -P 0 echo >/dev/null {}
                               |  
-----------+---------+---------+----------------------------------------------------- 
fred.bear  | 10m 12s | 1.5 GiB | * echo FILENAME >/dev/null
                               | $ time names=( hello\ * ) ; time for (( ix=0, cnt=${#names[@]} ; ix<$cnt; ix++ )) ; do echo "${names[ix]}" >/dev/null ; done
-----------+---------+---------+----------------------------------------------------- 
l0b0       | ?@#!!#  | 1.7 GiB | * echo FILENAME >/dev/null 
                               | $ time  while IFS= read -rd $'\0' path ; do echo "$path" >/dev/null ; done < <( find "$HOME/junkd" -type f -print0 )
                               | Note: It started processing filenames after 7 minutes.. at this point it  
                               |       started lots of disk thrashing.  'find' was using a lot of memory, 
                               |       but in its basic form, there was no obvious advantage... 
                               |       I pulled the plug after 20 minutes.. (my poor disk drive :(
-----------+---------+---------+----------------------------------------------------- 
intuited   | ?@#!!#  |         | * print line (to see when it actually starts processing, but it never got there!)
                               | $ ls -f hello * | xargs python -c '
                               |   import fileinput
                               |   for line in fileinput.input(inplace=True):
                               |       print line ' 
                               | Note: It failed at 11 min and approx 0.9 Gib
                               |       ERROR message: bash: /bin/ls: Argument list too long  
-----------+---------+---------+----------------------------------------------------- 
Reuben L.  | ?@#!!#  |         | * One var assignment per file
                               | $ ls | while read file; do x="$file" ; done 
                               | Note: It bombed out after 6min 44sec and approx 0.8 GiB
                               |       ERROR message: ls: memory exhausted
-----------+---------+---------+----------------------------------------------------- 

Une autre opportunité pour la découverte complètement sûre :

while IFS= read -rd $'\0' path
do
    file_path="$(readlink -fn -- "$path"; echo x)"
    file_path="${file_path%x}"
    sed -i -e 's/blah/blee/g' -- "$file_path"
done < <( find "$absolute_dir_path" -type f -print0 )

Ceci est principalement hors sujet, mais vous pouvez utiliser

find -maxdepth 1 -type f -name '*.txt' | xargs python -c '
import fileinput
for line in fileinput.input(inplace=True):
    print line.replace("blah", "blee"),
'

Le principal avantage ici (sur ... xargs ... -I {} ... sed ...) est la vitesse: vous évitez d'invoquersed 10 millions de fois. Ce serait encore plus rapide si vous pouviez éviter d'utiliser Python (car python est un peu lent, relativement), donc perl pourrait être un meilleur choix pour cette tâche. Je ne sais pas comment faire l'équivalent facilement avec perl.

La façon dont cela fonctionne est d' xargsinvoquer Python avec autant d'arguments qu'il peut tenir sur une seule ligne de commande, et de continuer ainsi jusqu'à épuisement des arguments (fournis par ls -f *.txt). Le nombre d'arguments pour chaque invocation dépendra de la longueur des noms de fichiers et, euh, d'autres éléments. La fileinput.inputfonction génère des lignes successives à partir des fichiers nommés dans les arguments de chaque invocation, et l' inplaceoption lui dit de "capturer" par magie la sortie et de l'utiliser pour remplacer chaque ligne.

Notez que la replaceméthode de chaîne de Python n'utilise pas de regexps; si vous en avez besoin, vous devez les import reutiliser print re.sub(line, "blah", "blee"). Ce sont des RegExps compatibles Perl, qui sont en quelque sorte des versions fortement enrichies de celles que vous obtenez sed -r.

Éditer

Comme le mentionne akira dans les commentaires, la version originale utilisant un glob ( ls -f *.txt) à la place de la findcommande ne fonctionnerait pas car les globs sont traités par le shell ( bash) lui-même. Cela signifie qu'avant même l'exécution de la commande, 10 millions de noms de fichiers seront substitués dans la ligne de commande. Il est à peu près garanti de dépasser la taille maximale de la liste d'arguments d'une commande. Vous pouvez utiliser xargs --show-limitspour des informations spécifiques au système à ce sujet.

La taille maximale de la liste d'arguments est également prise en compte par xargs, ce qui limite le nombre d'arguments qu'elle passe à chaque appel de python en fonction de cette limite. Comme il xargsfaudra encore invoquer python plusieurs fois, la suggestion d'Akira d'utiliser os.path.walkpour obtenir la liste des fichiers vous fera probablement gagner du temps.

Essayer:

ls | while read file; do (something to $file); done