Seite 1 von 2

ExplorerGadget: Wie Pfad ohne Filterpattern richtig angeben?

Verfasst: 16.02.2018 01:19
von DarkSoul
Hallo,

Ich habe eine ganz doofe Frage. :mrgreen:

In der Dokumentation von PureBasic steht zum Direktory$-Parameter von ExplorerTreeGadget():
If no pattern is included, the directory must end with a '\'. Including no directory will display the root containing the drives. Including no pattern defaults to '*.*'. So a Directory$ of "" will display the root and set '*.*' as pattern.
Mir ist diesbezüglich in meinen Programmen ein kleines Problem aufgefallen.

Wenn ich keine Pattern nutzen möchte, muss ich als Directory z.B. "/home/usernameblabla/\" übergeben. Funktioniert soweit.

Wenn sich im Homeverzeichnis jedoch ein Unterordner mit dem Namen "\" befindet, dann lande ich in diesem. Das soll nicht passieren.

Wenn ich das abschließende "\" weglasse, dann funktioniert es trotzdem wie gewünscht. Ich nehme mal an, dass manche Linux-Distributionen dies jedoch explizit verlangen.

Wie mache ich das richtig?

Muss ich stattdessen "/home/usernameblabla/*.*" verwenden? Oder muss ich den Backslash escapen? Wozu ist der Backslash gut? :oops:

Re: ExplorerGadget: Wie Pfad ohne Filterpattern richtig ange

Verfasst: 16.02.2018 02:47
von ccode_new
@Darksoul

/ oder \ am Ende ist bei Linux egal.

Es können aber Probleme beim Parsen von bestimmenten Sonderzeichen im String auftretten.

Z.B. bei diesem '

Dieses Zeichen im Ordername kann manchmal falsch übergeben werden und beendet an seiner Stelle den Verzeichnis-String.

Re: ExplorerGadget: Wie Pfad ohne Filterpattern richtig ange

Verfasst: 16.02.2018 03:59
von DarkSoul
Das ist nicht egal, da "\" auch ein Ordner sein kann. Damit kann es kein Trennzeichen sein.

/home/bla/a\b/ ist unter Linux ein gültiger Pfad, wovon "a\b" das letzte Verzeichnis ist.

Ich kenne das so:

Windows = \
Linux = /

Aber ich rede nicht von den Trennzeichen im Pfad, sondern von dem Backslash, den ExplorerTreeGadget am Ende haben möchte. Der hat IMHO nichts mit den Pfadtrennzeichen zu tun./:->

Und warum sollte ein ' den Verzeichnisstring beenden? Ein " wäre da viel problematischer, wenn der PB-Compiler das schlucken würde. Aber auch nur dann, wenn der String im Code ist. Ein ", das in einem String im Arbeitsspeicher ist, ist PB dagegen egal.

Re: ExplorerGadget: Wie Pfad ohne Filterpattern richtig ange

Verfasst: 16.02.2018 04:24
von ccode_new
:mrgreen:

Naja so einfach ist das nicht.

Es ist richtig das "\" auch ein Ordner sein kann, dieser wurde (zumindest bei mir) immer auch bei der Parameterübergabe an ExplorerTreeGadget() korrekt als Ordner ausgewerdet.

Es kann aber trotzdem eine Fehlerquelle darstellen.

Auch bei so etwas: /verzeichnis1/\/verzeichnis3\

Aber es kann je nach Parameterübergabe( versch. Input) zu Verwechselungen( falsch Interpretationen) des Apostrophe und des (einfachen) Anführungszeichens kommen. (Zeichensatzfehler)

Re: ExplorerGadget: Wie Pfad ohne Filterpattern richtig ange

Verfasst: 16.02.2018 11:52
von NicTheQuick
Die Dokumentation ist einfach nur falsch. Die bezieht sich nur auf Windows. Unter Linux und Mac muss natürlich einfach nur ein / am Ende stehen.

Re: ExplorerGadget: Wie Pfad ohne Filterpattern richtig ange

Verfasst: 16.02.2018 13:22
von DarkSoul
Die Dokumentation ist einfach nur falsch.
Ist das wirklich sicher? Ich meine, das wäre doch mal aufgefallen. ExplorerTreeGadget() gibt es schon eine ganze Weile. :shock:

Ich habe mir dafür extra eine Methode geschrieben: "Wenn keine Pattern, dann stückel ein "\" dran" :freak: .
Es kann aber trotzdem eine Fehlerquelle darstellen.
Die wäre?
Aber es kann je nach Parameterübergabe( versch. Input) zu Verwechselungen( falsch Interpretationen) des Apostrophe und des (einfachen) Anführungszeichens kommen.
Wovon sprichst du? Als Parameter wird ein String übergeben. Ein String steht bei PB zwischen zwei ". Es ist genau definiert, wie PB einem String im Code interpretieren soll. Was sollen da für Vewechselungen stattfinden? Und ich glaube, dass man das " auch in PB per \" escapen kann (habe ich jetzt nicht versucht). Und wenn der String erstmal im Speicher ist, dann wird da auch nichts mehr geparst ooder sonstwas. Höchstens, wenn externe Programme im Spiel wären, die per Konsolenparameter aufgerufen werden. Aber das wäre ein völlig anderes Thema. :wink:

Re: ExplorerGadget: Wie Pfad ohne Filterpattern richtig ange

Verfasst: 16.02.2018 15:04
von ccode_new
Wovon sprichst du? Als Parameter wird ein String übergeben. Ein String steht bei PB zwischen zwei ". Es ist genau definiert, wie PB einem String im Code interpretieren soll. Was sollen da für Vewechselungen stattfinden? Und ich glaube, dass man das " auch in PB per \" escapen kann (habe ich jetzt nicht versucht). Und wenn der String erstmal im Speicher ist, dann wird da auch nichts mehr geparst ooder sonstwas. Höchstens, wenn externe Programme im Spiel wären, die per Konsolenparameter aufgerufen werden. Aber das wäre ein völlig anderes Thema.
Du hast Recht, es ist ein völlig anderes Thema.

Es hat nichts mit dem ExplorerTree/List - Gadget zu tun.

Es ist einfach nur ein dämliches Kommentar von mir und kann hierbei vollkommen ignoriert werden.

Das Problem der Übergabe liegt bei mir am Auslesen von Textdateien die statt als UTF8-Codierung als "Reiner Text" ausgelesen werden.

Re: ExplorerGadget: Wie Pfad ohne Filterpattern richtig ange

Verfasst: 16.02.2018 18:21
von DarkSoul
Seit wann kann man mit utf-8 Bilder speichern? Das ist reiner Text. Meinst du Ascii? :wink:

utf-8 und Ascii unterscheiden sich erst ab dem 128. Zeichen. ', ", ´, \ und / wären von einer Fehlinterpretation nicht betroffen. <)

Selbst, wenn du einen utf-8-String versehntlich als #PB_Ascii bzw, als Abfolge von Bytes blind aus dem Speicher holst und woanders wieder als #PB_Ascii reinschreibst, bleibt er am Ende utf-8-codiert und nichts dramatisches würde passieren, außer dass du selber Grütze im String hast, was du aber nicht bemerkst, wenn du ihn selber nicht verarbeitest.

Zeichenkodierungen sind nichts weiter als Standards, wie die Bytes, die sich tatsächlich im Speicher befinden, als Text darzustellen sind. Also welche Bytefolge welchem Zeichen entspricht. Der Unicode-Zeichensatz passt nunmal nicht in den Wertebereich 0-255 eines Bytes. Selbst mit ucs-2 ist es bereits eng geworden.

Eklig wird es daher erst, wenn der String unter Verwendung einer falschen Zeichencodierung verarbeitet wird bzw. die Bytefolgen wieder in Zeichen verwandelt werden oder umgekehrt. (z.B. Ascii-Textdateien als utf-8 lesen und ausgeben)

Re: ExplorerGadget: Wie Pfad ohne Filterpattern richtig ange

Verfasst: 16.02.2018 18:44
von ccode_new
Dieser Zeichenkodierungsbug scheint aber nur unter Linux aufzutreten.

Unter Windows wird das UTF - 8217 Zeichen richtig dargestellt.

Es wird auch unter Linux das korrekte Zeichen ("Unicode Character 'RIGHT SINGLE QUOTATION MARK' (U+2019)") übergeben.

Aber bei unformatierten Textdateien wird das irgend wie unter Linux als falsches Zeichen interpretiert. (8242)

Wenn man das Zeichen aber einfach nur kopiert und per Zeicheneditor überprüft gibt dieser das korrekte Zeichen an. (8217)

Dieser "Bug" tritt bei mir nur unter Linux auf.

Re: ExplorerGadget: Wie Pfad ohne Filterpattern richtig ange

Verfasst: 16.02.2018 18:53
von DarkSoul
Ich bin von Ascii Nr. 39 ausgegangen. :roll:

Ansonsten kann ich dir nicht folgen. Ich weiß nicht, von was für einem Bug du da sprichst und was das mit den Pfadangaben von ExplorerTreeGadget zu tun haben soll... Wenn das bei dir nicht richtig gelesen wird, verwendest du eine falsche Zeichenkodierung bzw. verwechselst den Kodierungsstandard (utf/ucs) mit dem Unicode-Zeichensatz.