staging.inyokaproject.org

Hallo zusammen,

zwar weiß ich, dass mit regulären Ausdrücken große Mengen an Dateien bzw. Dateinamen schnell und perfekt geändert werden können, kenne mich bisher aber damit so gut wie nicht aus. Und entsprechende Abhandlungen sind verwirrend für mich. Dennoch sind mir erste Aktionen gelungen. So z.B. habe ich Doppelpunkte, Klammern und Leerzeichen entfernt sowie Unterstriche eingefügt, aber trotz endloser Versuche will es mir nicht gelingen, Punkte zu entfernen: Ein Kommando, das beispielsweise in anderen Fällen wirkt, funktioniert bei Punkten auch entsprechend angepasst nicht. Für "Klammer auf" (die einfach nur weg sollte) habe ich dieses hier benutzt:

-execdir rename -E 's/\(//' -E 's/\s$//' {} \+

Für Punkte in Dateinamen habe ich es mit diesem versucht:

-execdir rename -E 's/\./-/' -E 's/\.$/_/' {} \+

Es klappt nicht. Zu Testzwecken habe ich in einem Testordner das Verzeichnis 0_Test_1995 angelegt und darin die Dateien A_12.12.95 und B_M.Mustermann. Das Kommando aber gibt aus:

Can't rename ./. -/.: No such file or directory
Can't rename ./0_Test_1995 -/0_Test_1995: No such file or directory
Can't rename ./A_12.12.95 -/A_12.12.95: No such file or directory
Can't rename ./B_M.Mustermann -/B_M.Mustermann: No such file or directory

Ich habe lange gesucht und viele Kommando-Varianten ausprobiert, aber diese Hürde schaffe ich bisher nicht. Offenbar wird im Fall von Punkten ergebnislos nach Verzeichnissen und Dateien gesucht, die mit "./" beginnen - aber warum? Was bei anderen Details in Dateinamen funktioniert, scheitert hier am Punkt, obwohl er maskiert ist. Wie müsste denn stattdessen das Kommando beginnen, damit es nicht immer gegen die Wand läuft und Punkte in Dateinamen tatsächlich zu Bindestrichen werden?

Viele Grüße

nenem

@nenem find setzt die Dateinamen mit einem führenden ./ als Argument ein, damit Dateinamen die mit - oder -- beginnen, nicht von dem Kommando, welches man ausführen will, als Optionen interpretiert werden können. Was im besten Fall zu Fehlern führt, und im schlechteren Fall von einem Angreifer ausgenutzt werden kann um da Optionen einzuschmuggeln.

Du musst die Ersetzung also so formulieren, dass das führende ./ unberührt bleibt. Denn das Problem ist ja nicht der Quellname, sondern dass die Zielnamen dann alle mit -/ anfangen.

Es scheint auch so als würde da nur der erste Punkt ersetzt, ich vermute aber mal das alle Punkte in den Namen ersetzt werden sollen‽

Zur letzten Anmerkung: Ist richtig. Bei so etwas gehe ich nur step by step vor, damit ich genauer beobachten kann, was passiert - oder eben nicht. Die Verwendung von "g" kommt dann später.

Genau in die Richtung, die Du zuerst beschrieben hast, habe ich ja vermutet. Nur wundert mich erstens, dass die Kommandos bei anderen Sachverhalten (wie z.B. Doppelpunkt oder Klammer) funktionieren, beim Punkt aber nicht. Für mich ist eben zweitens die große Frage: Wie formuliere ich die Ersetzung, damit das führende "./" unberührt bleibt?

@nemen: Warum wundert Dich das? Das Problem ist ja nicht der Quellname, sondern der Zielname wenn ./some.name in -/some.name umbenannt werden soll, dann fehlt halt ein Verzeichnis das - heisst. Wenn ./some(name in ./some-name umbenannt wird, gibt es das Problem natürlich nicht, weil der . am Anfang beim Ersetzen einer Klammer nicht verändert wird.

Nachvollziehbar, aber es ändert an meinem Hauptproblem nichts (das auch der Grund für mein Thema hier war/ist): Dass ich nicht weiß, wie diese Hürde zu nehmen ist. Wie muss das Kommando ggf. erweitert werden, damit die Ersetzung von Punkten durch Bindestriche in Dateinamen klappt? Hast Du eine Idee?

Ich habe es jetzt nicht wirklich getestet, sondern nur mit sed simuliert, aber versuche einmal, statt des Ausdrucks

's/\./-/'

den Ausdruck

's#\([^/]\)\.#\1-#'

zu verwenden.

Sich mal gründlich mit regulären Ausdrücken auseinander setzen. Die Lösung ist hier IMHO sehr einfach, allerdings mit einem ”speziellen” Konstrukt dass es mehr bringt wenn Du Dir die Lösung selbst erarbeitest. Sonst läuft das am Ende darauf hinaus, dass Du immer nur fertige Lösungen bekommst, dabei aber selbst nicht wirklich etwas lernst.

Dabei können auch interaktive Werkzeuge helfen. Die gibt es sowohl als Programme, als auch Online. https://regex101.com/ zum Beispiel.

@wxpte: Funktioniert nicht mit führenden Punkten. Es sei denn, die sollten tatsächlich erhalten bleiben.

$ echo ./.name.with.dots | sed 's#\([^/]\)\.#\1-#g'
./.name-with-dots

@Marc_BlackJack_Rintsch Es funktioniert leider ganz anders, als erwartet, da rename sich anders verhält, als sed Insbesondere wird die Gruppe im Suchmuster bei der Ersetzung nicht als \1 repräsentiert. Hab's gerade getestet.

Probier mal es auf die einfache Art:

$ find -type f -name "*.*" -exec bash -c "d=\$(dirname \"{}\");a=\$(basename \"{}\");b=\"\${a//./-}\";echo mv \"{}\" \"\$d/\$b\"" \; 
mv ./0_Test.1995/B_M.Mustermann ./0_Test.1995/B_M-Mustermann
mv ./0_Test.1995/A_12.12.95 ./0_Test.1995/A_12-12-95
$ 

Es kann ja sein, dass die Verzeichnisse auch Punkte aufweisen. Die Umbenennung bezieht sich daher nur auf die Dateinamen (-type f). Aber dabei wird die übliche Trennung zwischen Datei-Name und Datei-Typ aufgehoben. Es wäre hilfreich, wenn man mal ein konkretes Beispiel (ist → soll) hätte. Das obige Beispiel listet nur den Befehl, der ausgeführt würde (echo). Nach Löschen des "echo" werden die Befehle umgesetzt.

Soweit ich es überblicke, haben die Verzeichnisse keine Punkte, sehr viele Dateien aber schon - und die gibt es hier massenhaft. Wenn ich es richtig sehe, bezieht sich Dein Vorschlag ja auf die beiden Dateien, die ich als Muster angelegt habe, um hier nicht riesige Codeblöcke zu erstellen. Wenn ich mich nicht täusche, scheidet diese Lösung deshalb aus. Edit (erstmal auf die Schnelle): War ein Irrtum, weil ich Deinen Satz zunächst nicht richtig verstanden hatte. Es funktioniert zwar, aber immer noch nicht ganz wie es soll. Dazu später mehr.

Beispiele hatte ich ja eigentlich genannt: Die Datei A_12.12.95 soll zu A_12-12-95 werden und B_M.Mustermann zu B_M-Mustermann. Dateiendungen/-typen gibt es bisher nicht. Entstanden sind sie nämlich vor Ewigkeiten auf einem Mac mit dem Programm Ragtime 3.2, und damals bekamen sie keine Endungen verpasst. Unter Ubuntu werden sie nicht erkannt - allerdings dann geöffnet, wenn dazu LibreOffice genutzt wird. Insofern ist meine Idee, an alle Dateinamen die Endung ".odt" anzuhängen. Wollte ich mir vornehmen, nachdem das aktuelle Problem (hoffentlich) gelöst ist. Wie gesagt: Es sind sehr viele Verzeichnisse mit Unmengen an Dateien.

Als Ergänzung zu meinem "Edit" oben:

Dein Kommando-Vorschlag habe ich mit echo ausprobiert allerdings ohne -type f . Funktioniert:

mv . ./-
mv ./0_Testordner_1995/A_12.12.95 ./0_Testordner_1995/A_12-12-95
mv ./0_Testordner_1995/B_M.Mustermann ./0_Testordner_1995/B_M-Mustermann

Das tatsächliche Ergebnis ohne echo ist einwandfrei. Die Dateien wurden umbenannt.

Als ergänzenden Test habe ich einen Unterorder "1_Testordner_Mai" hinzugefügt und darin die Datei "C_22.5.95". Der Test mit echo ergibt:

mv . ./-
mv ./0_Testordner_1995/1_Testordner_Mai/C_22.5.95 ./0_Testordner_1995/1_Testordner_Mai/C_22-5-95
mv ./0_Testordner_1995/A_12.12.95 ./0_Testordner_1995/A_12-12-95
mv ./0_Testordner_1995/B_M.Mustermann ./0_Testordner_1995/B_M-Mustermann

Beim Test ohne echo wurden alle Dateien umbenannt wie bei echo, aber zusätzlich wird ausgegeben:

mv: das Verschieben von '.' nach './-' ist nicht möglich: Das Gerät oder die Ressource ist belegt.

Was das zu bedeuten hat, weiß ich nicht. Ist vermutlich nicht wichtig, denn das Ergebnis stimmt ja. So müsste eigentlich alles funktionieren, wenn hoffentlich die vielen Ordner damals alle ohne Verwendung von Punkten ausgekommen sind. Wenn so etwas nämlich ins Spiel kommt, sieht die Sache - trotz des gelöschten "-type f" - nämlich anders aus. Zu diesem Zweck habe ich den Unterordner testweise umbenannt in "1_Testordner_Mai.25" und das Kommando nochmal mit Echo drüberlaufen lassen. Ergebnis:

mv . ./-
mv ./0_Testordner_1995/1_Testordner_Mai.25 ./0_Testordner_1995/1_Testordner_Mai-25
mv ./0_Testordner_1995/1_Testordner_Mai.25/C_22.5.95 ./0_Testordner_1995/1_Testordner_Mai.25/C_22-5-95
mv ./0_Testordner_1995/A_12.12.95 ./0_Testordner_1995/A_12-12-95
mv ./0_Testordner_1995/B_M.Mustermann ./0_Testordner_1995/B_M-Mustermann

Die praktische Seite: Der Inhalt von 0_Testordner_1995 wurde komplett umbenannt - also sowohl der Unterordner, als auch die beiden Dateien - der Inhalt des Unterordners aber nicht. Dort ist es bei der Datei C_22.5.95 geblieben. Meine Vermutung: Als bei Abarbeitung der Maßnahmen die Datei umbenannt werden sollte, gab es den Ordner 1_Testordner_Mai.25 nicht mehr, sondern nun 1_Testordner_Mai-25, und das Kommando lief ins Leere.

Wenn also irgendwelche der vielen Ordner und Unterordner einen oder mehrere Punkte im Namen enthalten, bleibt deren Inhalt unverändert: Die darin enthaltenen Dateinamen haben weiterhin Punkte.

Wie gesagt: Ich meine, dass es solche Fälle nicht gibt, weiß es aber nicht mit Sicherheit. Zur Not muss ich alles händisch nachkontrollieren, ob so etwas irgendwo passiert ist (oder es vorher tun, um solche Probleme zu vermeiden) - es sei denn, dem Kommando kann etwas hinzugefügt werden, was diese Folge verhindert.

Für das Ändern in Unterverzeichnissen könnte der Schalter -depth nötig sein, damit Dateien vor Verzeichnissen umbenannt werden, denn find sammelt erst alle Dateinamen und findet dann Verzeichnisse nicht, wenn sie zwischenzeitlich umbenannt wurden.

@shiro und @user_unknown: Mit dem Kommando und dem Schalter funktioniert es einwandfrei. Vielen Dank.

Allerdings hat sich eine schwerwiegende Nebenwirkung gezeigt. Sie hat(te) mit meinem speziellen Anwendungsfall zu tun: Nach der Bearbeitung konnten die Dateien am alten Mac nicht mehr geöffnet werden.

Hintergrund: Hier ist unter Ubuntu der Emulator Basilisk II zusammen mit dem Mac-System 7.5.3 installiert. Diese Konstellation entspricht der meines sehr alten Macintosh Classic II, der nach Reparatur wieder in Betrieb gehen soll. Mit der Kombination aus Ubuntu und Emulator will ich den alten Datenbestand bereinigen, bevor er wieder auf den alten Rechner kommt. Fast 100% der damals entstandenen Dateien wurden mit dem Office-Programm RagTime 3.2 generiert, und der Dateimanager des Mac-Systems zeigt sie mir alle als RagTime 3 Dokument an. Die vorher von mir verwendeten Kommandos ließen diesen Zustand unberührt - anders übrigens, als Änderungen von Dateinamen auf der grafischen Oberfläche von Ubuntu: Entsprechende Tests hatten zur Folge, dass die Dateien im Mac-System nun als Dokument erschienen und nicht mehr geöffnet werden konnten. Genau das passierte bei der aktuellen Aktion auch: Für das Mac-System wurden sie unbrauchbar. Daraufhin bin ich noch einmal zu dem Kommando zurückgekehrt, dass nur Dateien ändert, aber keine Verzeichnisse - also mit der Sequenz -type f. Damit passierte es nicht, und die Dateien ließen sich mit dem Mac-System und RagTime 3 öffnen.

Offenbar hat es mit 2 Ordnern zu tun hat, die in allen originalen Ordnern vertreten sind: .finf und .rsrc. Generiert wurden und werden sie, wenn mit dem Mac-System auf sie zugegriffen wird. Insbesondere .finf dürfte Einstellungen enthalten. Wenn sich durch die Kommando-Bearbeitungen an den Dateien etwas ändert, wird unter Ubuntu bei .finf nämlich auch das jeweilige Änderungsdatum angezeigt. Was genau in den Dateien hinterlegt ist, die sich in .finf befinden, weiß ich nicht, denn sie lassen sich nicht öffnen (auch mit einem Texteditor nicht). Klar war nur, dass diese Ordner unbrauchbar werden, sobald Ordnernamen bei der Eliminierung von Punkten einbezogen werden: Aus .finf wird dann -finf. Dementsprechend werden auch Dateien vom Mac-System nicht mehr richtig erkannt.

Die Lösung habe ich inzwischen gefunden: Nach dem Kommando zur Eliminierung von Punkten muss noch einmal das einfachere drüberlaufen, um -finf wieder in .finf umzubenennen und -rsrc in .rsrc. Dann funktioniert wieder alles so, wie es soll. Uff... 😉

Hat hier noch niemand die Option -d von rename empfohlen? Das wäre doch mal der erste Schritt um zu verhindern, dass Verzeichnisse umbenannt werden.