ExcludeTrailingPathDelimiter defekt

[himitsu]

Wieso liefert ExcludeTrailingBackslash/ExcludeTrailingPathDelimiter seit Jahrzehnten ein falschs Ergebnis für Root-Verzeichnisse?

Delphi-Quellcode:

ExtractPath('D:\aaa\bbb') = 'D:\aaa\'
ExtractDir('D:\aaa\bbb') = 'D:\aaa'
ExcludeTrailingPathDelimiter('D:\aaa\') = 'D:\aaa'

ExtractPath('D:\aaa') = 'D:\'
ExtractDir('D:\aaa') = 'D:\'
ExcludeTrailingPathDelimiter('D:\') = 'D:'  // So, nun ist das plötzlich ein relativer Pfad, obwohl er vorher absolut war.

ExtractFileDir(IncludeTrailingPathDelimiter('D:\') + 'dummy') = 'D:\'  // bescheuertste Lösung

[Sir Rufo]

Der liefert doch nicht das falsche Ergebnis ... sondern da passiert genau das, was der Name verspricht

(Du erwartest da etwas anderes, das mag sein ... allerdings lässt der Name nicht hoffen, dass du hier mit deiner Erwartung richtig liegst)

[himitsu]

Es geht auch andersrum zu Argumentieren.
* das Ding soll "nur" den "abschließenden" Delimiter entfernen, also den Letzten
* der erste "Delimiter" ist aber kein Delimiter zwischen zwei Verzeichnisnamen, sondern er gibt die Relation an
und schon stimmt der Funktionsname dennoch.
OK, beim alten ExcludeTrailingBackslash sah das noch anders aus.

ExcludeTrailingPathDelimiter(ExtractFilePath('C:\dir\dat.ei')) = ExtractFileDir('C:\dir\dat.ei') ?

[Sir Rufo]

Der PathDelimiter ist der übergeordnete Begriff für Backslash - das ist der PathDelimiter unter Windows.

Also sollten beide unter Windows exakt gleich arbeiten.

Wenn du ExcludeTrailingBackslash richtig deutest, dann sollte das mit ExcludeTrailingPathDelimiter jetzt auch funktionieren

Oder mal anders gesagt:

Diese Funktionen entfernen bei einem string das letzt Zeichen, wenn es sich hierbei um den PathDelimiter (Backslash) handelt. Mehr gibt die Bezeichnung auch nicht her.

Da wird nichts weiter interpretiert.

ExtractPath bzw. ExtractDir interpretieren den Wert dagegen schon hinsichtlich des Root-Eintrags.

[Christian Seehase]

Zitat von Sir Rufo:

Der PathDelimiter ist der übergeordnete Begriff für Backslash - das ist der PathDelimiter unter Windows.

Da muss ich Dich leider korrigieren

Unter Windows sind \ und / als Pfadtrennzeichen gleichberechtigt.

z.B.:
C:\DIR\DAT.EI
wird von Windows genauso interpretiert wie:
C:/DIR/DAT.EI
oder auch
C:\/////\\\\\DIR/////\/\DAT.EI

[Sir Rufo]

Das ist doch nicht schlimm ...

... Delphi hängt unter Windows den Backslash als PathDelimiter dran.

[himitsu]

Das Problem ist halt, dass C:\DIR\DAT.EI nicht gleich C:DIR\DAT.EI ist, bzw. C: ist nicht C:\
Denn der erste "Pathdelimiter" hat halt eine etwas "andere" Funktion.

Genau so, wie bei einer URL die ersten beiden // auch keine Pathdelimiter sind, bzw. die gehören nichtmal zum Pfad. (sind quasi die Trennzeichen zwischen Protokoll und Pfad/Daten)

[Sir Rufo]

Wenn man es ganz genau nimmt, dann gibt es ein (oder mehrere) Zeichen, die ein PathDelimiter sind.

Das ist einfach mal so.

Jetzt gibt es aber für diese PathDelimiter innerhalb eines bestimmten Kontext unterschiedliche Bedeutungen. Diese Bedeutungen erschließen sich allerdings auch erst durch den Kontext und nicht einfach durch eine einzelne Betrachtung des Zeichens.

Da IncludeTrailingPathDelimiter und IncludeTrailingBackslash diesen Kontext nicht beachten du aber etwas benötigst, dass den Kontext beachtet gilt schon mal Folgendes:

Zitat:

Das sind nicht die Droiden die Ihr sucht!

Gib doch mal eine Liste der Eingaben und der gewünschten Ausgaben vor, dann findet sich auch die Funktion dazu.

[BUG]

Ich würde SirRufo zustimmen: Vom Namen her ist das Ding ist eine Stringfunktion, die nichts über Semantik weiß.
Der Artikel hier ist vielleicht ganz interessant für dich.

[jaenicke]

Nun, eine Standardverwendung ist z.B. Zum Zusammenbauen eines Verzeichnis-Strings.
Wenn die Funktionen da nicht immer gleich funktionieren würden, kämen ggf. Verzeichnisse mit doppelten Pfadtrennzeichen usw. heraus.