Ordnernamen in Variable schicken

Zitat von Schnuffel

es gibt Menschen, die suchen Fehler geben aber keine Hilfestellung.

Schlechte Unterstellung.
Ich habe eine einfachere Alternative zur Nicht-RegEx-Lösung gegeben.

Und warum man erst die Initiative einleitet mit "alle mir gerade einfallenden [...] Eventualitäten mit abzufangen" und dann auf Hinweise, dass es eben noch weitere Eventualitäten gibt diese Diskussion dann wieder abwürgt ist ebenso nicht verständlich.

Erstmal denke ich kommen hier alle mal wieder runter!

Ich denke was Schnuffel eher meinte war "zu erwartenden Eventualitäten" und ja man kann das natürlich auch noch weiter führen und den RegEx erweitern auf ([[:alpha:]]:.*\\|\\{2}.*\\|.*\/)(.*)\b

Ich denke niemand ist Perfekt und es wird immer Nachbesserungsbedarf geben, denn was so manch ein DAU irgendwo eingibt, da staunt man doch so manchesmal als ITler

Zitat von Moombas

Ich denke niemand ist Perfekt und es wird immer Nachbesserungsbedarf geben, ...

Meine Großeltern sagten mir, dass ich perfekt sei. Und ich stimme zu. Perfekte Menschen programmieren nicht. Sie sind perfekt, so wie sie sind.

Zitat

#include <MsgBoxConstants.au3>

Example()
Func Example()
; Create a constant variable in Local scope of the message to display in FileSelectFolder.
Local Const $sMessage = "Select a folder"

; Display an open dialog to select a file.
Local $sFileSelectFolder = FileSelectFolder($sMessage, "")
If @error Then
; Display the error message.
;~ MsgBox($MB_SYSTEMMODAL, "", "No folder was selected.")
ConsoleWrite("No folder was selected." & @CRLF)
Else
; Display the selected folder.
;~ MsgBox($MB_SYSTEMMODAL, "", "You chose the following folder:" & @CRLF & $sFileSelectFolder)
ConsoleWrite("You chose the following folder: >" & $sFileSelectFolder & "<" & @CRLF)
EndIf
Local $sParentFolder = StringLeft($sFileSelectFolder, StringInStr($sFileSelectFolder, "\", 0, -1) - 1)
ConsoleWrite("+ $sParentFolder >" & $sParentFolder & "<" & @CRLF)
Local $sChildFolder = StringTrimLeft($sFileSelectFolder, StringInStr($sFileSelectFolder, "\", 0, -1))
ConsoleWrite("+ $sChildFolder >" & $sChildFolder & "<" & @CRLF)
EndFunc ;==>Example

Alles anzeigen

Ich glaube, der OP versucht, den übergeordneten Ordner vom untergeordneten Ordner (dem ausgewählten) zu trennen.
Wenn ich mich nicht irre

Manchmal frage ich mich welche Diskussion hier geführt wird. Der Einzeiler mit stringsplit ist erst nach mehrmaligem Hinsehen verständlich, funktioniert aber tadelsfrei. Ich gebe zu ich habe den Einzeiler auch erst "ausprobiert" bevor ich genau verstanden habe was da "getrieben" wird!

Ob er 1/100 s schneller oder langsammer ist ? Wem juckt es in der Praxis? Keinen? Genau. Das ist (von ein paar ganz wenigen Anwendungen abgesehen) nur "falcher Ehrgeiz". Zumal gar nicht bewiesen ist, ob die Lösung mit stringsplit tatsächlich "langsam" ist. Weshalb also den Hilfesuchenden verunsichern? Bei der ganzen Diskusion wird dann (wenn ich es nicht versehnetlich überlesen habe) sofern man nach einer anderen Lösung sucht, die naheligeste mit stringsplitright übersehen.

Also stopt das Verunsichern eines Fragestellers....

Peter

Es geht nicht um performanter. Es geht um einfacher verständlich oder alternativ alle Fälle abdeckend.
Die Variante bei der eine Funktion aufgerufen wird und direkt dessen Rückgabe als Index wiederrum diesen Funktionsaufruf erhält ist mit Sicherheit verunsichernder als eine einfache String*()-Lösung.
Die in sich verschachtelte StringSplit-Lösung ist nicht die naheliegendste.

Und ansonsten entscheidet jeder für sich selbst, worüber er diskutieren möchte.
Das lässt sich hier keiner diktieren.
Das Forum und dessen Inhalte sind nicht ausschließlich auf die Problemlösung von Fragestellern ausgerichtet sondern ebenso ein Diskussionsforum für das eigene Hobby.
Würde eine Diskussion drumherum nicht zugelassen, gäbe es das Forum nicht mehr, da das Interesse der potentiell Helfenden verschwände.

Also stopp Versuche eine freie Diskussionen zu unterdrücken.

Und ganz ehrlich: Manchmal entstehen eben durch Diskussionen Ideen/Lösungen die vorher keiner im Sinn hatte.

Diskussionen finde ich immer gut, solange es Sachlich bleibt. Würde man immer das erste Ergebnis nehmen was einem Präsentiert wird, wären wir wohl immer noch in der Steinzeit.

Ja, nur das deine erstbeste Lösung keine Steinzeitlösung ist. Ich habe auch an stringright gedacht als ich die Frage des TE-Erstellers sah. Und ja die Antwort von Moobas ist schwer verständlich, als ich sie gelesen habe, dachte ich zuerst, der spricht chinesisch. Nach Ausprobieren, und anständig Drüberschauen, war mir klar was Moobas vorgeschlagen hatte. Es funktioniert reibungslos.

Klar je länger man über etwas spricht, desto mehr Lösungen tauchen auf, nur eine Lösung zu "diskreditieren" weil sie, unbewiesen, angeblich etwas langsamer ist --> macht das Sinn?

Und ja Autoit ist unser "Berufsergänzungs Hobby" und diskutieren gehört dazu - nur ob es für einen Hilfesuchenden immer sinnvoll ist? Im übrigen fällt mir dann bei der Gelegenheit ein, dass man es sich als einfacher User, von Powerusern gefallen lassen muss, dass Antworten in einer Diskussion ausgeblendet werden? Wer also sollte ermahnt werden eine freie Diskussion zuzulassen? Den Link zu meinem "Ausblendungsbeispiel" kann ich gerne nachreichen. Man findet Ihn aber hier im Forum, erst vor kurzem!

Peter

um den Möglichkeiten weiteren Raum zu geben hier noch eine Alternative, die sich DOS zu Nutze macht.

#include <Array.au3>
$Test = _BatSplitPath(@ScriptFullPath)
_ArrayDisplay($Test)

Func _BatSplitPath($sPath)
	Local $aReturn[5]
	If FileExists($sPath) Then
		Local $iPID = Run(@ComSpec & ' /C "FOR %I IN ("' & $sPath & '") DO @ECHO %~dI^|%~pI^|%~nI^|%~xI"', "", @SW_HIDE, 2)
		ProcessWaitClose($iPID)
		Local $aOutput = StringSplit(StringReplace(StdoutRead($iPID), '"', ''), '|')
		For $i = 1 To $aOutput[0]
			$aReturn[$i] = $aOutPut[$i]
		Next
		$aReturn[0] = $sPath
		Return $aReturn
	Else
		$aReturn[0] = $sPath
		SetError(1,0,$aReturn)
	EndIf
EndFunc

Zitat von Peter S. Taler

diskutieren gehört dazu - nur ob es für einen Hilfesuchenden immer sinnvoll ist?

Nochmal: Es geht nicht ausschließlich um den Hilfesuchenden.
Das hier ist kein Dienstleistungsunternehmen.
Die Leute helfen hier weil es Ihnen Spaß macht und machen es nur in der Art wie es ihnen Spaß macht.
Der Gewinn ist für alle da, wenn beides unter einen Hut gebracht werden kann.
Mag sein dass die anschließende Diskussion den Fragenden nicht weiter bringt - und?
Er hat dennoch genug Lösungen erhalten.
Rückmeldung gab es ja eh nicht.

Wir können uns noch so oft einreden, dass wir aus einem irgendwie gearteten Altruismus heraus allein hier sind um anderen zu helfen.
Wenn man jedoch mal ehrlich und objektiv darüber nachdenkt kommt man am Ende darauf, dass man es tatsächlich nur für sich selbst macht.

Zitat von Peter S. Taler

Wer also sollte ermahnt werden eine freie Diskussion zuzulassen?

Du. Deine übergriffige Aussage, dass wir bestimmte Diskussionen unverzüglich zu unterlassen haben ist völlig daneben.

Zitat von Peter S. Taler

nur eine Lösung zu "diskreditieren" weil sie, unbewiesen, angeblich etwas langsamer ist --> macht das Sinn?

Es fand hier nirgends eine Diskreditierung statt. Es wurden verschiedene Varianten hinsichtlich ihrer Eigenschaften bewertet und verglichen.
Dass eine Erkenntnis war, dass eine Lösung vermutlich etwas weniger performant ist, ist keine Diskreditierung.
Wir werden auch in Zukunft derartige Bewertungen vornehmen.
Der Anspruch den einige (mich eingeschlossen) hier haben ist jeweils bestmögliche Lösungen zu finden.
Und diese findet man nicht ohne Diskussion.
Diese mögen für den konkreten Fragesteller overdosed sein aber es geht um Wiederverwendung für andere in anderen Szenarien.

Zitat von Peter S. Taler

Ja, nur das deine erstbeste Lösung keine Steinzeitlösung ist. Ich habe auch an stringright gedacht als ich die Frage des TE-Erstellers sah. Und ja die Antwort von Moobas ist schwer verständlich, als ich sie gelesen habe, dachte ich zuerst, der spricht chinesisch. Nach Ausprobieren, und anständig Drüberschauen, war mir klar was Moobas vorgeschlagen hatte. Es funktioniert reibungslos.

Und genau darum geht es... Das die Lösung funktioniert hat niemand abgestritten. Ich hab wegen Schnuffels Verwirrung geantwortet und dabei eine Übersichtlichere Lösung angeboten, die zusätzlich noch performanter ist... Außer dir hat das niemand kritisiert.

Zitat von Peter S. Taler

Klar je länger man über etwas spricht, desto mehr Lösungen tauchen auf, nur eine Lösung zu "diskreditieren" weil sie, unbewiesen, angeblich etwas langsamer ist --> macht das Sinn?

Je mehr Lösungen, desto besser ist das meiner Meinung nach für den Thread ersteller. Und auch andere, die nach dem Problem suchen, können sich das dann anschauen und sehen, was für Möglichkeiten es gibt => können noch Ansätze,... lernen. Das ist doch gerade für Anfänger interessant. Warum also bei der ersten Lösung aufhören, wenn man lust hat weiter darüber nachzudenken.
Und ich denke nicht, dass ich hier die erste Lösung "diskreditieren". Ich hab sie mir angeschaut, war auch ne Sekunde verwirrt, bis ichs mir angeschaut habe um es zu verstehen... Wenn man als Softwareentwickler schon ne Sekunde braucht (mit Hintergrundwissen, was in dem ersten Array-Index steht,...) wie soll das dann ein Anfänger verstehen? Also ist es doch nur sinnvoll, eine weitere Lösung anzubieten.
Dabei gehe ich natürlich auch auf die jeweiligen Vor-/Nachteile ein, so wie ich sie als Softwareentwickler einschätze. Das ist kein "diskreditieren" und auch nicht "unbewiesen/angeblich", sondern basiert auf der eigenen Erfahrung, was im Hintergrund abläuft und wie lange das ggf. dauert. Da ich es nicht gemessen und damit bewiesen habe, habe ich extra ein "vermutlich" dazugeschrieben.

Und weil ichs jetzt genau wissen wollte habe ich jetzt ein Programm zum nachmessen geschrieben:

#include <Array.au3>
Local $arFuncs = ["_FolderWithStringSplitShort", "_FolderWithStringSplit", "_FolderWithStringSplitDataOnly", "_FolderWithStringRight", "_FolderWithStringTrimLeft", "_FolderWithRegExp", "_FolderWithRegExpExt", "_FolderWithRegExpExtSecond"]
Local $sTestPath = "C:\Users\User\Desktop\SomeFolder\Folder"
Local $iCalls = 1000000

Local $iMaxLength = 0
For $i=0 To UBound($arFuncs)-1 Step 1
	If $iMaxLength<StringLen($arFuncs[$i]) Then
		$iMaxLength = StringLen($arFuncs[$i])
	EndIf
Next

Local $arResult[UBound($arFuncs)][2]
For $i=0 To UBound($arFuncs)-1 Step 1
	Local $iInit = TimerInit()
	For $j=0 To $iCalls Step 1
		Call($arFuncs[$i], $sTestPath)
	Next
	Local $iDiff = TimerDiff($iInit)
	$arResult[$i][0] = $arFuncs[$i]
	$arResult[$i][1] = $iDiff
Next

_ArraySort($arResult, 0, 0, 0, 1)

Local $sFormat = "%"&$iMaxLength&"s: % 10.2f ms >> 1 Call: % 10f ms"
For $i=0 To UBound($arResult)-1 Step 1
	ConsoleWrite(StringFormat($sFormat, $arResult[$i][0], $arResult[$i][1], $arResult[$i][1]/$iCalls)&@crlf)
Next


Func _FolderWithStringSplitShort($sPath)
	Return Stringsplit($sPath, '\')[Stringsplit($sPath, '\')[0]]
EndFunc

Func _FolderWithStringSplit($sPath)
	Local $arPath = Stringsplit($sPath, '\')
	Return $arPath[$arPath[0]]
EndFunc

Func _FolderWithStringSplitDataOnly($sPath)
	Local $arPath = Stringsplit($sPath, '\', BitOR(1,2))
	return $arPath[UBound($arPath)-1]
EndFunc

Func _FolderWithStringRight($sPath)
	Return StringRight($sPath, StringLen($sPath)-StringInStr($sPath, "\", 0, -1))
EndFunc

Func _FolderWithStringTrimLeft($sPath)
	Return StringTrimLeft($sPath, StringInStr($sPath, "\", 1, -1))
EndFunc

Func _FolderWithRegExp($sPath)
	Return StringRegExp($sPath, '.*\\(.*)', 2)[1]
EndFunc

Func _FolderWithRegExpExt($sPath)
	Local $sFolder = StringRegExp($sPath, '([[:alpha:]]:.*\\|\\{2}.*\\)(.*)\b', 1)
	If $sFolder = 0 Then Return SetError(1,0,"")
	Return $sFolder[1]
EndFunc

Func _FolderWithRegExpExtSecond($sPath)
	If StringLen($sPath) <= 3 Then
		Return StringLeft($sPath, 1) & ':\'
	Else
		$sFolder = StringRegExp($sPath, '([[:alpha:]]:.*\\|\\{2}.*\\)(.*)\b', 1)
		If $sFolder = 0 Then Return SetError(1,0,"")
		Return $sFolder[1]
	Endif
EndFunc

Ergebnis:

     _FolderWithStringTrimLeft:    7475.89 ms >> 1 Call:   0.007476 ms
        _FolderWithStringRight:    8337.42 ms >> 1 Call:   0.008337 ms
             _FolderWithRegExp:    8436.82 ms >> 1 Call:   0.008437 ms
          _FolderWithRegExpExt:    9146.73 ms >> 1 Call:   0.009147 ms
        _FolderWithStringSplit:    9954.14 ms >> 1 Call:   0.009954 ms
    _FolderWithRegExpExtSecond:    9990.07 ms >> 1 Call:   0.009990 ms
_FolderWithStringSplitDataOnly:   10245.97 ms >> 1 Call:   0.010246 ms
   _FolderWithStringSplitShort:   12759.48 ms >> 1 Call:   0.012759 ms

Wie erwartet:
- Die Mehrfachaufrufe von StringSplit sind langsamer.
- Interessanterweise ist die Methode "StringSplitDataOnly" langsamer als das normale "StringSplit", das extra Ubound scheint also durchaus einen unterschied zu machen. Performanter ist es also, mit dem ersten Index im Array zu arbeiten. (Hatte ich auch vermuted, deshalb wird es in C auch gemacht, ich finde es trotzdem vom Programmierstandpunkt schlechter, weil es in AutoIt inkonsistent ist. Manche Funktionen machen es, manche nicht, deshalb hatte ich es schon öfter, dass mir das auf die Füße gefallen ist. Deshalb stört es mich auch.)
- Die extra checks auf die Länge des Strings sorgen bei der letzten Regexp Lösung dafür, dass diese auch etwas langsamer ist.
- Ansonsten ist RegExp schneller als StringSplit, vmtl. weil es weniger im Speicher arbeitet um die ganzen Pfadteile abzuspeichern.
- Die String Methoden sind am schnellsten, weil sie den String nur einmal durchlaufen um das \ zu suchen und dann einmal durchgehen und abtrennen. Dabei ist StringTrimLeft schneller, weil es einmal weniger über den String iteriert, als StringRight mit, wo die Länge nochmal extra aufgerufen wird.

Ist das für den Threadersteller relevant? Nein.
Kann es für andere interessant sein, wo es ggf. einen Unterschied macht? Auch ja. Es kann ja jemand auf diesen Thread stoßen, der eine Excel-Datei mit millionen Einträgen durchgehen und verarbeiten will. Da kann es durchaus relevant sein.

Generell ist es sinnvoll, sich zumindest hin und wieder damit auseinander zu setzen, was denn Performanter ist und warum. Es wird bei anderen Fällen einen großen Unterschied machen.
Um zu wissen warum muss man sich nur mal die aktuelle Softwarewelt anschauen. Die Hardware wird immer Leistungsfähiger, die Programme laufen oft aber immernoch super langsam. Warum? Weil genau auf solche Dinge nicht geachtet wird... es ist ja schnell genug/genug Speicher da.
Ich will nicht wissen, wie viel aufgrund von nicht optimierter Software an Resourcen verbraten wird, oft auch nur, weil es (am Anfang) schneller/günstiger ist und sich das dann niemand wieder anschaut.

Es kommt immer aufs gleichgewicht zwischen Komplexität/Aufwand und der Performance an. Sollte man schnelle/kleine Dinge machen, die die Performance steigern: Klar. Sollte man riesen Aufwand betreiben um die letzte millisekunde herauszukitzeln? Nur wenn es wichtig ist.
Hier ist aber keine Lösung enorm Komplex/Aufwändig. Warum also nicht auch ein wenig auf die Performance schauen, man lernt etwas und es schadet niemandem.

Schnuffel Dürfte ich - zugegeben etwa vorsichtig formuliert - deiner spannenden Lösung eine Veränderung vorschlagen?

Der Umweg über eine tatsächliche Batch-Datei kann umgangen werden.
Man kann auch direkt die cmd.exe entsprechend aufrufen:

Local $iPID = Run(@ComSpec & ' /C "FOR %I IN ("' & $sPath & '") DO @ECHO %~dI^|%~pI^|%~nI^|%~xI"', "", @SW_HIDE, 2)

Diese Variante hätte zusätzlich auch den Vorteil, dass sie mit Leerzeichen im Ordnernamen klarkommt.

AspirinJunkie Danke, das mit dem direkten Aufruf habe ich nicht so hinbekommen.

Zitat von AspirinJunkie

AutoIt

Local $iPID = Run(@ComSpec & ' /C "FOR %I IN ("' & $sPath & '") DO @ECHO %~dI^|%~pI^|%~nI^|%~xI"', "", @SW_HIDE, 2)

Diese Variante hätte zusätzlich auch den Vorteil, dass sie mit Leerzeichen im Ordnernamen klarkommt.

Ich als alter DOSler bin immer wieder beeindruckt was man so alles mit einem Echo und co. machen kann.....

Um alle Verzeichnisse und Dateien zu bekommen könnte man aber auch "dir c:\ /s /b /q" machen....den Output entwerder in eine Dateiumleiten ">Verzeichnis.txt" oder den Output direkt zurückgeben und dann weiter mit AutoIT parsen...

Auch forfiles.exe kann man ganz tolle Sachen machen....

lg

Racer

AspirinJunkie

Du hast wohl Probleme mit Mitgliedern, die anderer Meinung sind als Du, oder Probleme mit der deutschen Sprache?

Was "übergriffig" ist - davon jedenfalls hast Du keine Ahnung. Ich empfehle einen Deutschkurs!

Wie sonst kannst Du so einen Unsinn schreiben?

Deine übergriffige Aussage, dass wir bestimmte Diskussionen unverzüglich zu unterlassen haben ist völlig daneben.

Wo steht das? Lerne lesen und verstehen!

Peter

Ich setze hier mal einen Schlusspunkt, ehe das hier noch irgendwie ausartet. Zumal der TE sich bisher nicht wieder gemeldet hat und das ursprüngliche Thema somit durch ist.