Reguläre Ausdrücke - Problem, bug oder einfach nur Unverständnis?

Matzbub

Folgendes Problem:

match$("([0-9{2}~s+[0-9]{2}~.pdf)","00 74.pdf") funktioniert tadellos

wenn ich aber mittels

addFiles "*.*",0
move("ListToArr",results$[])

die Dateinamen aus einem Verzeichnis lade und das results$[] Array mit einer While EndWhile Schleife durchlaufen lasse, dann wird vom selben RegEx die Datei mit dem Namen "00 74.pdf" nicht erkannt. Ersetzt man das + durch ein ? und lautet der Dateiname "0074.pdf", so wird die Datei erkannt, "00 74.pdf" jedoch weiterhin nicht. Nun habe ich sämtliche erdenkliche Varianten getestet, RegExe umgeschrieben, verworfen, neu formuliert. Alles funktioniert in RegEx Buddy und RegEx Tester super und fehlerfrei - nur nicht in XProfan X4. Tilde hin oder her... da werd' ich langsam "gaga".

Hat jemand ähnliche Erfahrungen gemacht oder ist jemand mittlerweile dahinter gekommen, was hier im Argen liegt? Oder hat jemand eine Idee, wie man ein Verzeichnis ohne den Umweg über eine Stringlist direkt mit einem Regulären Ausdruck durchsuchen kann?
Bin für jeden konstruktiven Hinweis extrem dankbar!!!

Matthias

Okay, interessant:
Mich hatte es einfach nicht in Ruhe gelassen. Ich beiße mich im Normalfall immer durch bis zum Schluss... Also:

Wenn man irgendeine andere Zahlenkombination abseits von "00" am Anfang nutzt, dann funktioniert es auch in XPROFAN X4. Mit beispielsweise "01" geht es, bzw. sobald es keine zwei Nullen sind. Ist leider aber unbrauchbar, weil die Dateinamen durch externe Bedingungen vorgegeben sind. Somit ist die match$() Funktion für den vorliegenden Fall unbrauchbar. Und streng genommen auch XPROFAN X4, weil es keine Alternative zu match$() gibt. Dummerweise hat die erstellte Software bereits Release Candidate Status und die RegEx Sache ist ansich eine essentielle Erweiterung, zur Optimierung der Funktionalität. Dumm gelaufen, würde ich sagen.

Der Fehler dürfte wohl in der Datenstruktur der Filelist liegen, denn hart kodierte Doppelnullen in der Match$("RegEx String","00 74") Funktion werden ja einwandfrei verarbeitet.

Aber vielleicht kann ja RGH hier noch einmal aktiv werden und der RegEx Option bzw. der Datenstruktur der Verzeichnisliste auf die Sprünge helfen. Wäre ein große Hilfe!!

Matthias

H.Brill

Ob nun hart kodiert oder Variable. Das dürfte keinen Unterschied machen.

Zeigt denn Listbox$("",2) die entsprechende Datei an ?

Und gibt IndexOf() den Fund zurück ?

Manchmal muß man halt von Grund auf vorgehen, um dem Problem zu Leibe zu rücken.

Matzbub

Hallo H.

Danke für Deine Hinweise. Ja, kann ich alles bestätigen.

In der Zwischenzeit habe ich auch noch versucht, das Ergebnis aus der Stringlist zu decodieren und umzuwandlen (UTF8/ANSI/OEM...) alles ohne Auswirkung auf das Ergebnis.

Sobald zwei Nullen hintereinander plus einem Leerzeichen den Anfang einer Variable oder eines Array Elements bilden, das der match$() Funktion übergeben wird, setzt die Erkennung aus.

Ich muss mich korrigieren:
Das trifft nur zu, wenn der Wert mit dem "AddFiles" Befehl eingelesen bzw. generiert wird

Jetzt wird es haarig...

Ich habe den Basis Code der Verzeichnisbearbeitung nun in ein neues (leeres) Programm kopiert und es funktioniert problemlos.

Die Dateien im Testverzeichnis heißen

00 74 012 902_09 10036083.pdf
01 74 012 902_09 10036083 - Kopie.pdf
0074 012 902_108 10036083 - Kopie.pdf

und werden allesamt von der match$() Funktion erkannt - ich habe keinerlei Erklärung

Der Oberhammer: ich habe nun den hier geposteten Code zurückkopiert in das Hauptprogramm - und es FUNKTIONIERT JETZT AUCH DORT! Leute, ich dreh' durch

Ich bin nach wie vor der festen Überzeugung: neben den binären 0 / I Werten existieren noch feine Nuancen... 100 Pro!

Code

Declare results$[], file$
'ChDir ".\Zwick Prüfprotokolle QS Metall"
AddFiles "*.pdf", 0
ListBox$("Ergebnis",1)
cls
move("ListToArr",results$[])

var i% = 0
whileNOT i% = sizeOf(results$[])
    file$ = match$("(^[0-9]{2}~s?[0-9]{2}~s+[0-9]{3}~s+[0-9]{3})",results$[i%])
    print file$
    inc i%
EndWhile
waitinput

Alles anzeigen

H.Brill

Mit Instr() + RegEx scheint es zu funktionieren. Da ich keine PFs hatte, habe ich mir .txt gemacht und in einen Ordner geschrieben.

Code

Move("ListToArr", result[])
WhileLoop 0, SizeOf(result[]) - 1
 If Instr("([0-9{2}~s+[0-9]{2}~.txt)",result[&LOOP]) <> 0
     Print $Match
 EndIf    
EndWhile

Ist schon manchmal seltsam.

Matzbub

Absolut

Bleibt dennoch die Frage, ob es eine Möglichkeit gibt, ein Verzeichnis gleich mittels RegEx auf das Vorhandensein von unterschiedlichen Dateinamen zu durchsuchen. Ohne den gesamten Inhalt zuvor in ein Array oder eine Stringlist einzulesen, und dann zu suchen.

Das wäre schon Bombe...

Professor Chaos

hab zwar nichts getestet, aber mir fällt ein erheblicher Fehler im RegEx selbst auf: Hinter deinem ersten "[0-9" fehlt ein "]"! Diesen Fehler hätte XProfan eigentlich melden müssen, auf jeden Fall würde ich damit eher zufällige statt zuverlässige Ergebnisse erwarten.

Probier auf jeden Fall mal stattdessen:

"([0-9]{2}~s+[0-9]{2}~.pdf)"

H.Brill

Hallo Professor Chaos,

Da findet man aber nur diejenigen, die ein Blank hinter den ersten zwei 00 haben.

Was bedeutet das

Code

~s+

dazwischen ? s ist doch KEIN Metazeichen.

Probier mal das :

Code

Declare String  result[]
Cls
Set("RegEx", 1)
chdir "F:\Files"
addFiles "*.*",0
Move("ListToArr", result[])
WhileLoop 0, SizeOf(result[]) - 1
 If match$("([0-9]{2} ?[0-9]{2}~.(?i)pdf)", result[&LOOP]) <> ""
     Print $Match
 EndIf
EndWhile

Waitkey

Alles anzeigen

Das Blank und ? da drin prüft halt, ob ein Blank 0 mal oder einmal drin vorkommt. Damit ist abgedeckt, daß auch alle Dateien, die kein Leerzeichen beinhalten, gefunden werden.

Die Dateinamenserweiterung habe ich mal auf Gleichheit der Groß-und Kleinschreibung eingestellt, falls mal ein z.b ".Pdf" auftaucht. Schaden tut es ja nichts.

H.Brill

Zitat von Matzbub

Aber vielleicht kann ja RGH hier noch einmal aktiv werden und der RegEx Option bzw. der Datenstruktur der Verzeichnisliste auf die Sprünge helfen. Wäre ein große Hilfe!!
Bleibt dennoch die Frage, ob es eine Möglichkeit gibt, ein Verzeichnis gleich mittels RegEx auf das Vorhandensein von unterschiedlichen Dateinamen zu durchsuchen. Ohne den gesamten Inhalt zuvor in ein Array oder eine Stringlist einzulesen, und dann zu suchen.
Matthias

Sowas ähnliches hatte ich schon vor Jahren RGH vorgeschlagen. Soll heißen, bei welchen Stringfunktionen man noch RegEx unterstützen könnte. Speziell ging es um die Funktion SubStr$(), wo man demTrennzeichen (S2) einen regulären Ausdruck unterschieben könnte. Das ist vor allem bei .CSV - Dateien interessant, wo das Komma nicht unbedingt als Standard eingehalten wird und stattdessen oft ein Semikolon verwendet wird. Da muß man immer schon vorher wissen, welches Trennzeichen denn nun verwendet wird, um mit SubStr$() zu arbeiten. Besser wäre da ein

Code

S = "[,;]"  oder S = "(,|;)"

Damit könnte man dann direkt besser rausfischen, egal ob jetzt ein Komma oder Semikolon als Trenner vorhanden ist. Bei AddFiles kann ich mir das auch gut vorstellen, wenn man nicht nur mit "*.pdf" alle .pdf sondern spezieller unterscheiden könnte.

Ich denke, da gäbe es bestimmt auch noch mehr Sachen.

Matzbub

Stimmt, die Möglichkeiten für die Anwendung regulärer Ausdrücke sind tatsächlich ziemlich eingeschränkt. Wenn ich nur daran denke, dass keine backreferences unterstützt werden. Da muss man manchmal richtig Klimmzüge machen, um die entsprechenden Funktionen doch irgendwie hinzubekommen. Aber das schärft ja wiederum das Hirn

Jedenfalls habe ich nun alles Nötige tip topp realisiert bekommen. Ansich könnte man diesen Thread hier löschen, denn die ursprüngliche Situation hatte sich durch das hin- und herkopieren des Quellcodes ja erledigt.

Alles Gute an die Profaner Community

Reguläre Ausdrücke - Problem, bug oder einfach nur Unverständnis?

Jetzt mitmachen!

Tags