Fehler in der deutschen Hilfe bitte hier melden (Hilfedatei 3.3.14.5 2020.04.13)

  • Hallo Leute, hier ein kleiner Fall.


    _PathFull()


    Als erstes steht da:


    "Erstellt einen Pfad basierend auf dem relativen Pfad, der vom Benutzer übergegeben wird. Der neue absolute Pfad wird zurückgegeben"


    Dann steht bei Rückgabewert:


    "Gibt einen relativen Pfad zurück der relativ zu $sBasePath erzeugt wird. Um dieses Vorgehen zu verhindern ist ein absoluter Pfad zu verwenden."


    Das bei Rückgabewert ist doch irgendwie Unsinn, oder? (Das ist schon in der EN Hilfe so.)

  • Bitnugger Hihi, :P sehe ich genauso. Das hört sich an wie:


    "... Der neue absolute Pfad wird zurückgegeben, wenn sie einen alten absoluten Pfad eingeben." :D


    Aber mal im Ernst, das bei Rückgabewert stimmt einfach nicht. Es wird kein relativer Pfad zurückgegeben, sondern ein absoluter. Man gibt ein:


    "\..\..\test" und bekommt raus:

    "C:\Neuer Ordner\test"


    Somit könnte man den ersten Teil recht einfach korrigieren:


    Falsch: "Gibt einen relativen Pfad zurück der relativ zu $sBasePath erzeugt wird."

    Richtig: "Gibt einen absoluten Pfad zurück der relativ zu $sBasePath $sBaseDrive erzeugt wird. (Es kann zwar ein Pfad eingegeben werden, z. B. @ScriptDir, aber es wird nur der Laufwerksbuchstabe berücksichtigt.)"


    Scheinbar wird $sBasePath als $sBaseDrive benutzt, denn egal was ich eingegeben habe, es wurde nur der Laufwerksbuchstabe geändert.


    1. Beispiel:

    AutoIt
    Local $sTestPath = _PathFull("\..\..\test", "F:\Dir-1\Dir-2\Dir-3\Dir-4")
    MsgBox($MB_SYSTEMMODAL, "", @ScriptDir & @CRLF & $sTestPath)

    In diesem Beispiel lag mein Script (kompiliert oder nicht war egal) in


    "E:\Dir-1\Dir-2\Dir-3\Dir-4\test" => nach meinem Verständnis müsste herauskommen

    "F:\Dir-1\Dir-2\test" => aber es raus kam

    "F:\test"


    2. Beispiel

    Code
    Local $sTestPath = _PathFull("\Dir-1\Dir-2\test", "F:\Dir-1\Dir-2\Dir-3\Dir-4")
    MsgBox($MB_SYSTEMMODAL, "", @ScriptDir & @CRLF & $sTestPath)

    Auch in diesem Beispiel lag mein Script (kompiliert oder nicht war egal) in


    "E:\Dir-1\Dir-2\Dir-3\Dir-4\test" => nach meinem Verständnis müsste herauskommen

    "F:\Dir-1\Dir-2\Dir-3\Dir-4\Dir-1\Dir-2\test" => aber es raus kam

    "F:\Dir-1\Dir-2\test"


    Wie gesagt, für mich sieht es so aus, als ob nur der Laufwerksbuchstabe geändert/hinzugefügt wurde.


    Der zweite Teil unter "Rückgabewert" "Um dieses Vorgehen zu verhindern ist ein absoluter Pfad zu verwenden." macht nur bedingt Sinn. Wie Bitnugger schon sagte, dass "man sich den Umweg mit diese Funktion ersparen kann, wenn man direkt mit absoluten Pfaden arbeitet" scheint zuzutreffen. Gibt man einen absoluten Pfad ein, kommt der gleiche absolute Pfad raus.


    Summa summarum scheint es sich so zu verhalten:

    • Wird ein absoluter Pfad eingegeben, kommt der gleiche absoluter Pfad raus.
    • Wird ein relativer Pfad eingegeben, komm ein absoluter Pfad raus, relativ zu $sBasePath .
    • Allerdings scheint statt $sBasePath eher $sBaseDrive zu stimmen, denn nur der Laufwerksbuchstabe wird geändert/hinzugefügt.

    Was meint ihr dazu?

  • "E:\Dir-1\Dir-2\Dir-3\Dir-4\test" => nach meinem Verständnis müsste herauskommen

    "F:\Dir-1\Dir-2\Dir-3\Dir-4\Dir-1\Dir-2\test" => aber es raus kam

    "F:\Dir-1\Dir-2\test"

    Das wäre ja quatsch... dann könntest du auch einfach...

    $FullPath = $sBasePath & $sRelativePath

    ...schreiben.

    Local $sTestPath = _PathFull("\Dir-1\Dir-2\test", "F:\Dir-1\Dir-2\Dir-3\Dir-4")

    ===>>> F:\Dir-1\Dir-2\test


    Der Gedanke bei dieser Funktion war wohl, $sRelativePath in $sBasePath zu finden und den linken Teil, falls gefunden, der bei $sRelativePath fehlt, zu ergänzen... insgesamt betrachtet ist die Funktion aber eher ein Witz.


    Als ich mit AutoIt angefangen hatte, habe ich die Path-Funktionen natürlich auch alle getestet, bin aber schnell zu dem Schluss gekommen, dass ich es doch besser selbst mache, denn ich spiele nicht gerne russisches Roulett.


  • Da gebe ich dir in allen Punkten recht.

    Der Gedanke bei dieser Funktion war wohl, $sRelativePath in $sBasePath zu finden und den linken Teil, falls gefunden, der bei $sRelativePath fehlt, zu ergänzen.

    Bei meinen Tests habe ich genau das berücksichtigt und den Pfad sowohl im $sRelativePath als auch im $sBasePath entsprechen vorher erstellt. Ich weiß jetzt gerade nicht aus dem Stehgreif, ob Pfadangabe einfach so mit den Punkten angegeben werden können, z. B. @ScriptDir & "\..\..\MeinProgDir\test.txt". Dafür benutze ich _PathFull des öfteren.


    Edit: Gerade getestet:


    MsgBox(0, "", @ScriptDir & "\..\..\MeinProgDir\test.txt") => löst die Angaben mit den Punkten NICHT auf. Ergebnis:

    "E:\Dir-1\Dir-2\Dir-3\Dir-4\test\..\..\MeinProgDir\test.txt"

  • insgesamt betrachtet ist die Funktion aber eher ein Witz.


    Als ich mit AutoIt angefangen hatte, habe ich die Path-Funktionen natürlich auch alle getestet, bin aber schnell zu dem Schluss gekommen, dass ich es doch besser selbst mache, denn ich spiele nicht gerne russisches Roulett.

    Alle 4 Pfadfunktionen sind mit wenig Nutzen behaftet. Verwendet habe ich vor vielen Jahren mal _PathSplit, würde ich auch nicht mehr nehmen, einfach viel zu umständlich (für meinen Geschmack). Warum soll ich für jeden möglichen Pfadteil vorher eine Variable deklarieren, wenn ich dann nur 1 davon benötige und als Return sowieso ein Array mit allen Werten kommt?

    Aber man sollte dem Autor zugute halten, dass er eine Idee hatte und diese umgesetzt hat. Ich muss ganz ehrlich sagen, dass ich bei einigen meiner eigenen UDF nach heutigem Wissenstand durchaus auch an deren Notwendigkeit zweifle. :whistling:

  • _PathSplit, würde ich auch nicht mehr nehmen, einfach viel zu umständlich (für meinen Geschmack). Warum soll ich für jeden möglichen Pfadteil vorher eine Variable deklarieren, wenn ich dann nur 1 davon benötige und als Return sowieso ein Array mit allen Werten kommt?

    Was nutzt du denn statt _PathSplit?


    Und gibt es außer _PathFull eine andere Möglichkeit, um Pfadangaben mit Punkten in absolute Pfade zu wandeln? (z. B. @ScriptDir & "\..\..\MeinProgDir\test.txt")

  • Ich muss ganz ehrlich sagen, dass ich bei einigen meiner eigenen UDF nach heutigem Wissenstand durchaus auch an deren Notwendigkeit zweifle.

    Hihi, ja, das ist aber wohl bei allen Usern der Fall... einerseits erschreckend, was man da teilweise fabriziert hat, andererseits aber auch sehr belustigend und es zeigt einem vor allem aber auch, wie viel man zwischenzeitlich dazu gelernt hat. Ich splitte mir die Pfade meistens mit RegEx...

  • Was nutzt du denn statt _PathSplit?


    Und gibt es außer _PathFull eine andere Möglichkeit, um Pfadangaben mit Punkten in absolute Pfade zu wandeln? (z. B. @ScriptDir & "\..\..\MeinProgDir\test.txt")

    AutoIt
    #include <WinAPIFiles.au3>
    ConsoleWrite( _WinAPI_GetFullPathName("..\Beispiele\") & @CRLF)


    Ich verwende meine eigene Funktion: Pfad-Funktion mit Struktur

  • Ich verwende meine eigene Funktion: Pfad-Funktion mit Struktur

    Interessanterweise habe ich deine Funktion gerade gestern angeschaut, als ich nach einer Möglichkeit gesucht habe, um den Dateinamen + Endung aus einem Pfad zu bekommen.


    ConsoleWrite( _WinAPI_GetFullPathName("..\Beispiele\") & @CRLF)

    Genau sowas habe ich gesucht, das auch das kann:

    Code
    Local $sTestPath = "D:\Dir-A\Dir-B\Dir-C\"
    ConsoleWrite( _WinAPI_GetFullPathName($sTestPath & "..\..\Beispiele\") & @CRLF)

    Sowas brauche ich öffter, und damit funktionierts wunderbar. Danke dafür! :)

  • Nach dem Tipp von autoBert zeigt auch mein weiter oben beschriebener Fall das erwartete Ergebnis.


    Local $sTestPath = _PathFull("\Dir-1\Dir-2\test", "F:\Dir-1\Dir-2\Dir-3\Dir-4") ; <== Falsch.

    Local $sTestPath = _PathFull("Dir-1\Dir-2\test", "F:\Dir-1\Dir-2\Dir-3\Dir-4") ; <== Richtig.

    MsgBox($MB_SYSTEMMODAL, "", @ScriptDir & @CRLF & $sTestPath)


    Das sollte hinzugefügt werden. Ich nehme mal die Formulierung von BugFix als Grundlage. Mein Vorschlag:


    Erstellt einen absoluten Pfad aus einer relativen Pfadangabe ($sRelativePath) im Verhältnis zu $sBasePath. Relative Pfade dürfen nicht mit "\" beginnen. Wird $sBasePath angegeben, ist ein absoluter Pfad zu übergeben. Wird der $sBasePath weggelassen, wird standardmäßig @WorkingDir verwendet.


    Edit: Leichte Korrektur.

  • Man könnte noch einen Hinweis auf die Punkte hinzufügen (wie nennt man die eigentlich?) Wenn man in $sRelativePath einen semi-absoluten Pfad angibt, wird er von _PathFull als absoluter Pfad zurückgegeben. Beispiel:

    C
    #include <File.au3>
    #include <MsgBoxConstants.au3>
    Local $sTestPath = _PathFull(@ScriptDir & "\..\..\test") ; <== Wichtig: Hier muss auf den "\" geachtet werden
    MsgBox($MB_SYSTEMMODAL, "", @ScriptDir & @CRLF & $sTestPath)
  • Das ist eine Selbstverständlichkeit. Relative Adressierung geht nur mit "." oder ".."

    Also ich finde es gut, wenn es in der Hilfe dabei steht. Wie man in meinem Beipsiel oben sehen kann, macht einen so ein semi-rela-abso Pfad schonmal durcheinander. Da @ScriptDir keinen "\" zurückgibt (außer im LW-Root), muss man im relativen Teil der Pfadangabe einen "\" hinzufügen.


    _PathFull(@ScriptDir & "\..\..\test")


    So entsteht der Eindruck, man müsse halt standarmäßig vor dem "..\" ein "\" einfügen. Jetzt weiß ich, dass das nicht stimmt, aber vor dem Tipp von autoBert war mir das nicht klar.