Oh je, das hasst du so ne Leiche entdeckt
.
Dieser Teil in der Deutschen Hilfe stammt vom Inhalt und Layout her noch aus der AutoIt Version 3.3.8.1
.
Dann wurde es aber mal Zeit, dass das jemand entdeckt! 
Ich werde versuche es trotzdem zu aktualisieren (bin ja der einzige der das macht
)
Ich danke dir! 
Hallo Leute, hier ein kleiner Fall.
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.)
Damit meinen sie, das man sich den Umweg mit diese Funktion ersparen kann, wenn man direkt mit absoluten Pfaden arbeitet.
Bitnugger Hihi, 
sehe ich genauso. Das hört sich an wie:
"... Der neue absolute Pfad wird zurückgegeben, wenn sie einen alten absoluten Pfad eingeben." 
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:
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
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:
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.
#include <File.au3>
Local $FO = '%-92s %s\n'
ConsoleWrite(StringFormat($FO, '> abs 0 ' & _PathFull(''), ''))
ConsoleWrite(StringFormat($FO, '> abs 1 ' & _PathFull('Includes\'), ''))
ConsoleWrite(StringFormat($FO, '+ abs 2 ' & _PathFull('Includes\', 'c:\Program Files (x86)\AutoIt3\'), ''))
ConsoleWrite(StringFormat($FO, '+ abs 3 ' & _PathFull('Includes\', 'f:\_Archive\_Programmieren\'), ''))
ConsoleWrite(StringFormat($FO, '+ abs 4 ' & _PathFull('\Dir-1\Dir-2\test', 'F:\Dir-1\Dir-2\Dir-3\Dir-4'), ''))
ConsoleWrite(StringFormat($FO, '! abs 5 ' & _PathFull('\Dir-3\Dir-4\test', 'F:\Dir-1\Dir-2\Dir-3\Dir-4'), ' ===>>> F:\Dir-1\Dir-2\Dir-3\Dir-4\test'))
ConsoleWrite(StringFormat($FO, '+ abs 6 ' & _PathFull('\Dir-1\Dir-3\Dir-2\test', 'F:\Dir-1\Dir-2\Dir-3\Dir-4'), ''))
ConsoleWrite(@CRLF)
ConsoleWrite(StringFormat($FO, '! rel 0 ' & _PathFull('Includes\', '_Archive\_Programmieren\'), ' ===>>> _Archive\_Programmieren\Includes\'))
ConsoleWrite(StringFormat($FO, '! rel 1 ' & _PathFull('Includes\', '_Archive\_Programmieren\AutoIt3\'), ' ===>>> _Archive\_Programmieren\AutoIt3\Includes\'))
ConsoleWrite(@CRLF)
ConsoleWrite(StringFormat($FO, '+ abs a ' & _PathFull('\Dir-1\', 'F:\Dir-1\Dir-2\Dir-3\Dir-4'), ''))
ConsoleWrite(StringFormat($FO, '! abs b ' & _PathFull('\Dir-2\', 'F:\Dir-1\Dir-2\Dir-3\Dir-4'), ' ===>>> F:\Dir-1\Dir-2\'))
ConsoleWrite(StringFormat($FO, '! abs c ' & _PathFull('\Dir-3\', 'F:\Dir-1\Dir-2\Dir-3\Dir-4'), ' ===>>> F:\Dir-1\Dir-2\Dir-3\'))
ConsoleWrite(StringFormat($FO, '! abs d ' & _PathFull('\Dir-4\', 'F:\Dir-1\Dir-2\Dir-3\Dir-4'), ' ===>>> F:\Dir-1\Dir-2\Dir-3\Dir-4'))
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. 
_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")
#include <WinAPIFiles.au3>
ConsoleWrite( _WinAPI_GetFullPathName("..\Beispiele\") & @CRLF)Ich verwende meine eigene Funktion: Pfad-Funktion mit Struktur
Professor Bernd: Du benutzt den relativen Path falsch, dein erwartetes Ergebnis bekommst du mit:
#include <File.au3>
#include <MsgBoxConstants.au3>
Local $sTestPath = _PathFull("..\..\test", "F:\Dir-1\Dir-2\Dir-3\Dir-4")
MsgBox($MB_SYSTEMMODAL, "", @ScriptDir & @CRLF & $sTestPath)mfg (auto)Bert
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:
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! 
Professor Bernd: Du benutzt den relativen Path falsch, dein erwartetes Ergebnis bekommst du mit:
...
Local $sTestPath = _PathFull("..\..\test", "F:\Dir-1\Dir-2\Dir-3\Dir-4")
Ah, verstehe, der "\" am Anfang war zuviel.
Aber was machen wir nun mit der Beschreibung in der Hilfe? Kann das jemand so zusammenfassen, dass es einen Sinn ergibt?
Aber was machen wir nun mit der Beschreibung in der Hilfe? Kann das jemand so zusammenfassen, dass es einen Sinn ergibt?
Erstellt einen absoluten Pfad aus einer relativen Pfadangabe im Verhältnis zu einem Basispfad, welcher als absoluter Pfad zu übergeben ist. Standardmäßig ist dies @WorkingDir
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.
Relative Pfade dürfen nicht mit "\" beginnen.
Das ist eine Selbstverständlichkeit. Relative Adressierung geht nur mit "." oder ".."
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:
#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.