rklm schrieb:
user_unknown schrieb:
Unterschiede: Die Suche spezifisch schon auf Terra.X* beschränken und bei der Namensersetzung spricht auch nichts dagegen, genau Terra.X durch Terra_X zu ersetzen.
Wir wissen gar nicht, ob nur solche Dateinamen gemeint sind, oder auch welche mit mehreren Punkten aber ohne "Terra" vorkommen.
Du hast die Frage sorgfältiger gelesen als ich und Recht: Terra.X ist als Beispiel, nicht als einziges Muster genannt worden. Mein Fehler.
Du verwendest die überflüssige Variable f. Das geht auch direkt mit $1.
| mv $1 ${1/Terra.X/Terra_X}' -- {} ";"
|
Ja. An ${1/muster/replace}
kann ich mich schlecht gewöhnen. Ist nat. kein überzeugendes Argument.
Und die Konstruktion mit "for f ..." und "+" ist m.E. overengineered mit unnötiger Komplexität. Das Geschwindigkeit das erste Ziel ist, war nicht gesagt und fällt in die Kategorie premature optimization
. Wie lange kann es dauern, 10.000 Dateien umzubenennen? Gibt es überhaupt so viele Folgen?
Dafür läuft Deine Ersetzung Gefahr "Terra.X" irgendwo im Pfad in "Terra_X" zu ändern.
Nein. find -name MUSTER
findet MUSTER nicht im Pfad, und -execdir überreicht dem Kommando keinen Pfad, sondern nur den Dateinamen (bzw. "./NAME"). Der Punkt geht an mich. ☺
Und Du nutzt keine doppelten Anführungsstriche um den Dateinamen. Jaja, ich weiß, das ist Cargo-Kult für Dich, aber der Ärger und die Fehlersuche, die man sich dadurch sparen kann, sind es mir allemal wert. Zumal das gar kein zusätzlicher Aufwand für mich ist.
Wenn es Cargokult ist, dann braucht man keine, aber hier hast Du recht - man braucht welche:
| find -name "Terra.X.*.mkv" -execdir bash -c 'f=$1; mv -i "$f" "${f/Terra.X/Terra_X}"' -- {} ";"
|
Solche Medienproduktionen haben ja häufig Leerzeichen im Titel, und Downloadtools generieren gerne den Namen automatisch aus dem Titel - hier sind Leerstellen im Dateinamen fast vorprogrammiert, daher ist es nötig, Sorgfalt walten zu lassen.
Automatische Konversion der Leerstellen wäre natürlich noch besser. ☺
Konstruktionen mit find ... -(exec|ok)(dir)?
sind solchen mit | (while|for|xargs)
aber in der Regel vorzuziehen, weil man weniger Bohei machen muss, um gefährliche Dateinamen sauber zu behandeln.
xargs
ist genau so sicher wie -exec
, wenn man find ... -print0
und xargs -r0
nutzt.
Ich sagte "vorzuziehen", nicht "sicherer", und die Begründung war "Bohei", und "-print0" und "-r0" ist eben Bohei. ☺
Wie Du hinter der Pipe for
nutzen willst, ist mir allerdings nicht klar. while read
ist wohl die andere Option und da stimme ich Dir zu; hatte ich ja bereits geschrieben.
Will ich ja nicht, aber Du hast Recht, for kommt hinter der Pipe nicht in Frage.
| for f in $(find -name "Terra.X.*.mkv"); do echo mv -i "$f" "${f/Terra.X/Terra_X}"; done ;
|
wäre eine Möglichkeit, die aber auch weiteren Boheis bedarf, um Leerzeichen zu behandeln.
Dagegen ist mv -i
hilfreich. Es verhindert, dass eine Datei überschrieben wird.
Da nehme ich lieber "-n". Ansonsten hast Du das gleiche Problem mit den vielen Bestätigungen, das Du weiter oben anmerkst.
Nein, bei -okdir werde ich für jede Datei befragt, unabhängig davon, ob bereits eine gleichnamige da ist. Das mv -i
fragt mich aber nur, wenn es einen möglichen Nameclash gibt und verschiebt/umbenennt sonst mucksmäuschenstill tausende Files.
Shiros Idee, eine Parallelstruktur zum Testen zu machen, fand ich aber auch gut. ☺
Wozu? Du brauchst doch vor dem mv
nur ein echo
zu platzieren und die Ausgabe für die Analyse nach less
pipen. Da siehst Du dann doch genau, was nach was umbenannt wird.
Wenn jmd. zum ersten Mal find nutzt, und womöglich wenig Shellerfahrung hat, dann kann ja weit mehr schiefgehen. Da die Teststruktur selbst mit find erzeugt wird, beißt sich hier die Katze in den Schwanz, aber generell ist Testen zu begrüßen und das heißt nicht, das es nicht bessere Tests gibt.
Übrigens wissen viele User nicht, dass Thunar für's Massenumbenennen (>= 2 Dateien) einen Dialog anbietet, bei dem man auch reguläre Ausdrücke für die Umbenennung spezifizieren kann und auch eine Vorschau bietet, was wie umbenannt werden wird.
Nachteil: Steigt nicht rekursiv in Unterverzeichnisse ab - oh, dann hättest Du ja doch Recht, mit der Befürchtung, mein Befehl würde Verzeichnisnamen umbenennen - (Mist!); Vorteil: Man kann Dateien cherrypicken, die dem Umbenenennen unterzogen werden.