Come eseguire sed su oltre 10 milioni di file in una directory?

Ho una directory che contiene 10144911 file. Finora ho provato quanto segue:

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

Ho rotto il mio guscio, lsè in una tilda ma non riesco a capire come farne uno.

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

Troppi argomenti per sed

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

Non è più possibile biforcarsi più memoria

Altre idee su come creare questo gentile comando? I file non devono comunicare tra loro. ls | wc -lsembra funzionare (molto lentamente) quindi deve essere possibile.

Prova questo:

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

Alimenterà solo un nome file per ogni invocazione di sed. Ciò risolverà il problema "troppi argomenti per sed". L' -Popzione dovrebbe consentire a più processi di essere biforcati contemporaneamente. Se 0 non funziona (dovrebbe essere eseguito il maggior numero possibile), prova altri numeri (10? 100? Il numero di core che hai?) Per limitare il numero.

Ho testato questo metodo (e tutti gli altri) su 10 milioni di file (vuoti), denominati "ciao 00000001" a "ciao 10000000" (14 byte per nome).

AGGIORNAMENTO: Ora ho incluso una corsa quad-core sul 'find |xargs'metodo (ancora senza 'sed'; solo 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  

Ecco un riepilogo di come si sono comportate le risposte fornite quando eseguite rispetto ai dati di test sopra menzionati. Questi risultati riguardano solo le spese generali di base; cioè 'sed' non è stato chiamato. Il processo sed sarà quasi sicuramente il più dispendioso in termini di tempo, ma ho pensato che sarebbe stato interessante vedere come si confrontano i metodi nudi.

Il 'find |xargs'metodo di Dennis , usando un singolo core, ha richiesto * 4 ore e 21 minuti ** in più rispetto al bash arraymetodo in una no sedcorsa ... Tuttavia, il vantaggio multi-core offerto da 'find' dovrebbe superare le differenze di tempo mostrate quando viene richiesto sed elaborazione dei file ...

           | 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
-----------+---------+---------+----------------------------------------------------- 

Un'altra opportunità per la scoperta completamente sicura :

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 )

Questo è per lo più fuori tema, ma potresti usarlo

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

Il vantaggio principale qui (oltre ... xargs ... -I {} ... sed ...) è la velocità: eviti di invocare sed10 milioni di volte. Sarebbe ancora più veloce se tu potessi evitare di usare Python (dato che python è un po 'lento, relativamente), quindi perl potrebbe essere una scelta migliore per questo compito. Non sono sicuro di come fare l'equivalente convenientemente con il perl.

Il modo in cui funziona è che xargsinvocherà Python con tutti gli argomenti che può stare su una singola riga di comando e continuerà a farlo fino a quando non si esauriscono gli argomenti (che vengono forniti da ls -f *.txt). Il numero di argomenti per ogni invocazione dipenderà dalla lunghezza dei nomi dei file e, um, da alcune altre cose. La fileinput.inputfunzione produce righe successive dai file indicati negli argomenti di ogni invocazione e l' inplaceopzione dice di "catturare" magicamente l'output e usarlo per sostituire ogni riga.

Nota che il replacemetodo stringa di Python non usa regexps; se ne hai bisogno, devi import ree usalo print re.sub(line, "blah", "blee"). Sono RegExps compatibili con Perl, che sono una specie di versioni fortemente fortificate di quelle che ottieni sed -r.

modificare

Come Akira menziona nei commenti, la versione originale che utilizza un glob ( ls -f *.txt) al posto del findcomando non funzionerebbe perché i globs vengono elaborati dalla shell ( bash) stessa. Ciò significa che prima ancora che il comando venga eseguito, nella riga di comando verranno sostituiti 10 milioni di nomi di file. Questo è praticamente garantito per superare la dimensione massima dell'elenco di argomenti di un comando. È possibile utilizzare xargs --show-limitsper informazioni specifiche del sistema su questo.

Viene inoltre presa in considerazione la dimensione massima dell'elenco degli argomenti xargs, che limita il numero di argomenti che passa a ciascuna invocazione di Python in base a tale limite. Dato che xargsdovrà ancora invocare Python parecchie volte, il suggerimento di Akira da usare os.path.walkper ottenere l'elenco dei file probabilmente ti farà risparmiare un po 'di tempo.

Provare:

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