MUT: Sortierung Problem bei Punkt im Namen (Reihenfolge)

[phantom]

Hallo,

das Umbenenn-Tool ist recht komplex darum mag meine Lösung nicht richtig durchdacht sein aber funktional. Leider entstehen Fehler beim Umbenennen, wenn im Text Ziffern mit Punkt (Bspw.: 44.) vorkommen. Ich suche jetzt nicht unbedingt einen neuen Weg, sondern wüßte gerne den Grund für das fehlerhafte Verhalten.

Im Beispiel sollen Dokumente von 01-06 durch neue Namen aus einer Datei ersetzt werden.

Alter Dateiname:

Code: Select all

Dokument 01.doc
Dokument 02.doc
Dokument 03.doc
Dokument 04.doc
Dokument 05.doc
Dokument 06.doc

Name aus Datei:

Code: Select all

1.01 ABC gjdjddkgddhdhdjd öljlkj ljhlkhj
1.02 DEF zfuzfuzfuzfzuf lhklkhlh
1.03 FGH jhfhgf 45 ujhzfg jfgjhf jgjh
1.04 IJK kjgkj kjgk kjhg 44. kghkjg
1.05 LMN kjgh kjhgkjhkj kjgk kjhkjhkohfvhgfc
1.06 OPQ kgkl lkhjlkh lkjlkjljlk

In der Datei ist nur ein Teil des neuen Namen enthalten darum muss in einem zweiten Schritt der "neue" Dateiname noch ergänzt werden.

-> Lade Umbenennresultate für nächsten Schritt

Code: Select all

1.01 ABC gjdjddkgddhdhdjd öljlkj ljhlkhj
1.02 DEF zfuzfuzfuzfzuf lhklkhlh
1.03 FGH jhfhgf 45 ujhzfg jfgjhf jgjh
1.05 LMN kjgh kjhgkjhkj kjgk kjhkjhkohfvhgfc
1.06 OPQ kgkl lkhjlkh lkjlkjljlk
1.04 IJK kjgkj kjgk kjhg 44. kghkjg

Das Ergebnis zeigt, dass die Sortierung geändert wurde. Die Textzeile in der die Ziffer mit Punkt (44.) enthalten ist steht jetzt am Ende. Was nicht passieren sollte.

In der Umbenennmaske wird jetzt der neue vordere Teil eingesetzt. Da das Umbenenn-Tool den alten Namen durch den Präfix 1.01 als Erweiterung interpretiert füge ich den hinteren Teil durch "[E]" hinzu und füge per Hand die Erweiterung "doc" ein.

Die Umbenennmaske sieht also folgender Maßen aus (Dateiname.doc):

Code: Select all

Dateiname            | Erweiterung
---------------------------------------------                 
Neuer Dateiname NR[E]| doc

Code: Select all

Neuer Dateiname NR01 ABC gjdjddkgddhdhdjd öljlkj ljhlkhj.doc
Neuer Dateiname NR02 DEF zfuzfuzfuzfzuf lhklkhlh.doc
Neuer Dateiname NR03 FGH jhfhgf 45 ujhzfg jfgjhf jgjh.doc
Neuer Dateiname NR05 LMN kjgh kjhgkjhkj kjgk kjhkjhkohfvhgfc.doc
Neuer Dateiname NR06 OPQ kgkl lkhjlkh lkjlkjljlk.doc
Neuer Dateiname NR kghkjg.doc

Das Umbenennresultat macht die beiden Fehler durch "44." deutlich. Die Sortierung stimmt nicht mehr und der Text vor "44." wird abgeschnitten.

Kann der Fehler der durch "44." entsteht verhindert werden?

Vorschlag von Ghisler

Genau das ist falsch, weil die Namen aus der Textdatei eben noch KEINE Endungen enthalten!

Dashalb müssen Sie eben [E].doc und nicht nur doc eintragen, dann sollte es gehen.

Code: Select all

Dateiname            | Erweiterung
---------------------------------------------               
Neuer Dateiname NR   | [E].doc

Code: Select all

Neuer Dateiname NR.01 ABC gjdjddkgddhdhdjd öljlkj ljhlkhj.doc
Neuer Dateiname NR.02 DEF zfuzfuzfuzfzuf lhklkhlh.doc
Neuer Dateiname NR.03 FGH jhfhgf 45 ujhzfg jfgjhf jgjh.doc
Neuer Dateiname NR.05 LMN kjgh kjhgkjhkj kjgk kjhkjhkohfvhgfc.doc
Neuer Dateiname NR.06 OPQ kgkl lkhjlkh lkjlkjljlk.doc
Neuer Dateiname NR. kghkjg.doc

Wenn man die beiden Ergebnisse miteinander vergleicht, sieht man auf den ersten Blick keinen Unterschied. Schaut man genauer hin fällt auf, dass bei meinem Ergebnis zw. "NR01, NR02, NR03 ..." kein Punkt ist. Das ist gewollt deshalb habe ich völlig ungewohnt "[E]" in der Umbenennmaske für den Dateinamen eingetragen.

@Ghisler, wie Sie schon bemerken: bei "1.04 IJK kjgkj kjgk kjhg 44. kghkjg" hat es hinter "44" einen zusätzlichen Punkt. Deshalb sieht er 1.04 IJK kjgkj kjgk kjhg 44 als Namen und nur " kghkjg" als Erweiterung.

Das lässt sich sicher nicht verhindern, aber die ungewollte Änderung in der Sortierung müsste doch zu verhindern sein.

Meiner Meinung nach handelt es sich um einen Fehler, denn in der Vorschau wird die Sortierung noch korrekt angezeigt. Beim Laden der Resultatliste wird die Sortierung nach dem neuen Dateinamen vorgenommen obwohl der Umbenennprozess noch nicht beendet wurde.

[ghisler(Author)]

Irgend etwas stimmt nicht mit Ihrer Beschreibung: Sie gehen von 5 Dateien aus, laden dann aber die Namen aus einer Listendatei mit 6 Namen. Das Umbenenntool sollte das verweigern. Können Sie Ihre Beschreibung bitte überprüfen und korrigieren?

[phantom]

Sorry, ich hatte mit 5 Dateien begonnen und dies im Beispiel noch durch eine weitere ergänzt. Der Fehler wurde korrigiert. Die Ergebnisse habe ich direkt dem Total Commander entnommen.

[ghisler(Author)]

Lade Umbenennresultate für nächsten Schritt
Code:
1.doc
1.doc
1.doc
1.doc
1.doc
1.04 IJK kjgkj kjgk kjhg 44.doc

Diesen Schritt kann ich nicht nachvollziehen - ich bekomme die Namen angezeigt, die unter "Name aus Datei" stehen.

Haben Sie vielleicht im Feld "Erweiterung" doc statt [E] stehen? TC sieht alles nach dem LETZTEN Punkt als Erweiterung. Bei einem Namen wie
1.01 ABC gjdjddkgddhdhdjd öljlkj ljhlkhj
ist "1" der Name und "01 ABC gjdjddkgddhdhdjd öljlkj ljhlkhj" die Erweiterung.

Bei "1.04 IJK kjgkj kjgk kjhg 44. kghkjg" hat es hinter "44" einen zusätzlichen Punkt. Deshalb sieht er
1.04 IJK kjgkj kjgk kjhg 44
als Namen und nur " kghkjg" als Erweiterung.

Um .doc anzuhängen, dürfen Sie [E] nicht durch doc dersetzen, sondern durch [E].doc

[phantom]

In dem von ihnen zitierten Code habe ich tatsächlich einen Schritt vorweggenommen und in der Erweiterung schon "doc" eingetragen. Damit wird die Änderung bei der Sortierung hier schon sichtbar.

Bei "1.04 IJK kjgkj kjgk kjhg 44. kghkjg" hat es hinter "44" einen zusätzlichen Punkt. Deshalb sieht er 1.04 IJK kjgkj kjgk kjhg 44 als Namen und nur " kghkjg" als Erweiterung.

Da haben sie sicher Recht, das Verhalten habe ich mir zuvor ja zu nutze gemacht. Kann man es hier, da nicht gewollt, verhindern?

[ghisler(Author)]

In dem von ihnen zitierten Code habe ich tatsächlich einen Schritt vorweggenommen und in der Erweiterung schon "doc" eingetragen

Genau das ist falsch, weil die Namen aus der Textdatei eben noch KEINE Endungen enthalten!

Dashalb müssen Sie eben [E].doc und nicht nur doc eintragen, dann sollte es gehen.

[phantom]

@Ghisler, ich habe meinen ersten Beitrag nochmal überarbeitet. Es werden jetzt alle einzelnen Schritte angezeigt damit der Vorgang besser nachvollzogen werden kann. Ich habe auch ihren Vorschlag mal umgesetzt in die Erweiterung "[E].doc" einzusetzen. Das ändert aber nichts am falschem Ergebnis.

Ursache für das Problem ist "44." und die Interpretation von TC wie die Erweiterung zu ermitteln ist. Standardmäßig beginnt TC mit der Ermittlung der Erweiterung vom Ende her. Da ich dieses Verfahren für das Umbenennen recht häufig anwende wäre es sehr hilfreich, wenn man wahlweise festlegen könnte ob die Ermittlung der Erweiterung vom Anfang oder vom Ende erfolgen soll. Es dürfte für sie nicht allzu schwer sein dies noch einzubauen.

[Stefan2]

wäre es sehr hilfreich, wenn man wahlweise festlegen könnte ob die Ermittlung der Erweiterung vom Anfang oder vom Ende erfolgen soll.

Die Ermittlung der Erweiterung erfolgt immer vom Ende her.
Der letzte Punkt im Dateinamen bestimmt die Trennung zwischen Basename und Erweiterung.

Wenn du mehr als einem Punkt im Dateinamen hast, ist das oftmals ein Problem.
Versuche das zu vermeiden, benenne die Punkte temporär um, oder verwende eine Skriptsprache um das zu händeln.
(Tipp: MUT und 'Namen bearbeiten...' mit Texteditor mit Skriptierungsfunktion)
Das MUT alleine ist für all zu komplexe Aufgaben oft nicht die richtige Wahl.
Dafür ist es für die meistem täglichen Umbenennungen sehr gut geeignet.

Eventuell schau' ich mir die Woche mal deine Aufgabenstellung an......



EDIT:

Das Ergebnis zeigt, dass die Sortierung geändert wurde.
Die Textzeile in der die Ziffer mit Punkt (44.) enthalten
ist steht jetzt am Ende. Was nicht passieren sollte.

Ich habe mal den Erweiterungstrennpunkt durch ein '#'-Zeichen
ersetzt um den Sachverhalt deutlich zu machen:

1#01 ABC gjdjddkgddhdhdjd öljlkj ljhlkhj
1#02 DEF zfuzfuzfuzfzuf lhklkhlh
1#03 FGH jhfhgf 45 ujhzfg jfgjhf jgjh
1#05 LMN kjgh kjhgkjhkj kjgk kjhkjhkohfvhgfc
1#06 OPQ kgkl lkhjlkh lkjlkjljlk
1.04 IJK kjgkj kjgk kjhg 44# kghkjg

Du siehst, der TC sortiert korrekt.



- - -

Kann der Fehler der durch "44." entsteht verhindert werden?

Ersetze in "Name aus Datei:" alle Punkte nach dem Ersten temporär zB durch ein '#'-Zeichen
und dieses als letzten Umbenennschritt wieder zu einem Punkt.

zB für deinen Fall:

1.03 FGH jhfhgf 45 ujhzfg jfgjhf jgjh
1.04 IJK kjgkj kjgk kjhg 44. kghkjg

1.)
Suche: 1\.(.+)
Ersetze: 1?$1
[X]RegEx
1?03 FGH jhfhgf 45 ujhzfg jfgjhf jgjh
1?04 IJK kjgkj kjgk kjhg 44. kghkjg

2.)
Suche: \.
Ersetze: #
[X]RegEx
1?03 FGH jhfhgf 45 ujhzfg jfgjhf jgjh
1?04 IJK kjgkj kjgk kjhg 44# kghkjg

3.)
Suche: ?
Ersetze: .
[_]RegEx
1.03 FGH jhfhgf 45 ujhzfg jfgjhf jgjh
1.04 IJK kjgkj kjgk kjhg 44# kghkjg


(getestet mit PSPad)



- - -

Dann mit dem MUT umbenennen, neu laden und # zu Punkt ändern.




 

[phantom]

@Stefan2, ich kann deinen Lösungsansatz mit meinem Editor nachvollziehen, doch verstehen ist noch eine andere Sache. Regular Expression ist nochmal eine Bank für sich, da wollte ich mich immer schon mal mit beschäftigen. Aber man ist immer zu bequem. "\." ist ja noch verständlich, aber was bedeutet "(.+)" oder "$1". Merkwürdigerweise funktionieren deine RegEx Ausdrücke nicht beim TC, in meinem EmEditor wohl.

Im MUT gibt es unter den neuen Schaltern [+] und [#] noch Platz für einen dritten Schalter, dort könnte man solche Funktionen wie "Erweiterung vom Anfang oder vom Ende festlegen" gut unterbringen. Das würde auch die Symmetrie wiederherstellen.

[Stefan2]

"\." ist ja noch verständlich, aber was bedeutet "(.+)" oder "$1".

. = ein beliebiges Zeichen
\. = ein literaler Punkt (das RegEx-Zeichen 'Punkt' mittels Backslash seiner speziellen Bedeutung beraubt)
.+ = eins-oder-mehr von dem was links steht, hier "beliebiges Zeichen"
(...) = halte das, was gefunden wird, zur späteren Nutzung bereit
\1 oder $1 = gib das was in der 1ten (...)-Gruppe gefunden wurde, zurück

Merkwürdigerweise funktionieren deine RegEx Ausdrücke nicht beim TC,

Wahrscheinlich wegen des '?'-Zeichens?
Dieses ist im Dateinamen ungültig, und da TC ein Dateimanager ist...
Probiers mal mit einem Bindestrich anstelle des Fragezeichens.


Update: oben bei Schritt 1) würde ich noch ein Zirkumflex '^' vorneran stellen:
Suche: ^1\.(.+)
Das bedeutet dort: "finde am Anfang"

Und falls statt der '1' auch mal zB eine '2' stehen könnte,
machen wir den RegEx-Ausdruck etwas universeller:
1.)
Suche: ^(.)\.(.+)
Ersetze: $1?$2




 

[phantom]

@Stefan, vielen Dank für die Erläuterungen. Ich habe das "?" durch "~" ersetzt um das Umbenennen nur mit dem MUT zu machen. Das klappt zwar, aber ist derart aufwendig, dass es so keinen Sinn macht. Da bearbeitet man besser die Vorlage zuerst mit einem vernünftigen Editor oder erstellt am besten gleich ein Script bzw. ein Macro.

Bspw.:

Suche: ^(.)\.(.+)
Ersetze: $2

oder gleich

Suche: ^(.)\.(.+)
Ersetze: Neuer Dateiname NR$2\.doc

[phantom]

@Stefan, da du dich scheinbar mit RegEx gut auskennst, habe ich noch eine Frage zu meinem Problem.

Suche: ^(.)\.(.+)
Ersetze: $2

Der obere Ausdruck funktioniert einwandfrei. Doch bei manchen Vorlagen hat sich ein Fehler eingeschlichen. Manchmal steht hinter dem Punkt noch ein Leerzeichen. Kann man den automatisch beim Ersetzen löschen? Quasi das Leerzeichen am Anfang des Ausdrucks $2 löschen?

BSP.

$2 = "02 DEF zfuzfuzfuzfzuf lhklkhlh" --> OK

$2 = " 02 DEF zfuzfuzfuzfzuf lhklkhlh" --> Falsch

Wäre super, wenn dies in einem Durchlauf zu machen wäre.

[Hacker]

phantom,

Code: Select all

Suche: ^(.)\. *(.+)

HTH
Roman

[phantom]

Danke! Es wird echt mal Zeit mich mehr mit RegEx zu beschäftigen.

Code: Select all

  Suche: ^(.)\.\s*(.+)
Ersetze: $2

Ein Anfang.