PureBoard

Hallo,

Ich habe eine ganz doofe Frage.

In der Dokumentation von PureBasic steht zum Direktory$-Parameter von ExplorerTreeGadget():



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?

@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.

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.

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)

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.

Ist das wirklich sicher? Ich meine, das wäre doch mal aufgefallen. ExplorerTreeGadget() gibt es schon eine ganze Weile.

Ich habe mir dafür extra eine Methode geschrieben: "Wenn keine Pattern, dann stückel ein "\" dran" .



Die wäre?



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.

Seit wann kann man mit utf-8 Bilder speichern? Das ist reiner Text. Meinst du Ascii?

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)

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.

Ich bin von Ascii Nr. 39 ausgegangen.

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.