Beiträge von AspirinJunkie

Zitat von gmmg

Ich habe eben mal in dem FileWrite Abschnitt den Parameter in '";"' geändert. Hochkommas sind da.

FileWrite("merged.csv", _Array2CSV($aMerged, Default, '";"'))

Ne das wird so nicht funktionieren. Zumindest nicht, wenn du Werte mit Zeilenumbrüchen oder Anführungszeichen hast.
Und in deinem Beispiel war dies so.
Denn auf die Art hättest du doppelte Anführungszeichen am Wertanfang und das wäre nicht csv-konform.

Im Grunde ist es nicht viel Code um deinen String wie von dir gewollt zusammenzubauen

; 2D-Array in String konvertieren
Global $sOut = ""
For $i = 0 To UBound($aMerged) - 1

    ; 1. Spalte gesondert einfügen (sonst müsste man das letzte Semikolon am Ende entfernen)
    $sOut &= '"' & StringReplace($aMerged[$i][0], '"', '""') & '"'

    ; Die restlichen Spaltenwerte schreiben und dabei darauf achten, dass Anführungszeichen escaped werden
    For $j = 1 To UBound($aMerged, 2) - 1
        $sOut &= ';"' & StringReplace($aMerged[$i][$j], '"', '""') & '"'
    Next

    $sOut &= @CRLF
Next
; den letzten Zeilenumbruch entfernen
$sOut = StringTrimRight($sOut, 2)

; in Datei schreiben
FileDelete("merged.csv")
FileWrite("merged.csv", $sOut)

SOLVE-SMART
Schöne und womöglich bessere Lösung, da einfacher zu verstehen anstatt sich wie bei mir durch alle Spalten einzeln kämpfen zu müssen.

Zitat von gmmg

Eins ist mir noch aufgefallen. Bei einigen Datensätzen ist noch ein Hochkomma " im Merged drin.

Wie ich sagte, sind Zeilenumbrüchen innerhalb von Einzelwerten in csv nur dann erlaubt, wenn diese Werte in Hochkomma eingeschlossen werden.
Die Hochkomma müssen also zwangsläufig erscheinen wenn du Werte schreiben willst, welche Zeilenumbrüche enthalten.

Zitat von gmmg

Könnte man denn auch wieder die Texttrennzeichen "" mit in die Merge einfügen?

Nicht mit der _Array2CSV() bisher. Aktuell habe ich eine umfangreichere UDF in Arbeit, welche auch diese Funktionalitäten hier mit beinhaltet. Dort wird das dann mit drin sein als Switch.

Musst dir hierfür also was eigenes schreiben, was aber kein großes Problem ist, wenn du das 2D-Array schon vorliegen hast.

Bei deinen Dateien die du zuletzt hochgeladen hast stimmt etwas noch nicht.
In der einen Datei ist ein Header - in der anderen nicht.
Ich habe mich daher mal an die ursprünglichen @Tab-getrennten Daten gehalten und folgendes gebastelt:

 #include "parseCSV.au3"

; Beide CSV-Dateien in 2D-Array einlesen
$aCSV1 = _parseCSV('results-0.csv', True, False, @TAB)
$aCSV2 = _parseCSV('results-1.csv', True, False, @TAB)

; Zeilen angleichen falls doch unterschiedlich
If UBound($aCSV2) < UBound($aCSV1) Then Redim $aCSV2[UBound($aCSV1)][UBound($aCSV2, 2)]
If UBound($aCSV1) < UBound($aCSV2) Then Redim $aCSV1[UBound($aCSV2)][UBound($aCSV1, 2)]

; Array für merged-Daten dimensionieren
Local $aMerged[UBound($aCSV1)][UBound($aCSV1, 2) + UBound($aCSV2, 2)]

; Daten von beiden CSV-Arrays in Merged-Array übertragen
; Zeilenweise durchgehen
For $i = 0 To UBound($aCSV1) - 1
    ; Erst die Daten vom 1. Array
    For $j = 0 To UBound($aCSV1, 2) - 1
        $aMerged[$i][$j] = $aCSV1[$i][$j]
    Next

    ; Nun die Daten vom 2. Array
    Local $iOffset = $j
    For $j = 0 To UBound($aCSV2, 2) - 1
        $aMerged[$i][$j+$iOffset] = $aCSV2[$i][$j]
    Next
Next

; Kombinierte Daten wieder in eine CSV mit @Tab als Separator speichern^
FileDelete("merged.csv")
FileWrite("merged.csv", _Array2CSV($aMerged, Default, @TAB))

; Zum Schluss nochmal anzeigen
_ArrayDisplay($aMerged, "kombinierte CSVs", "1:", 64, "|", _ArrayToString(_ArrayExtract($aMerged,0,0)))

Edit: Und wenn du deinen alten, rein zeilenbasierten Ansatz weiterverfolgen willst, könntest du das Einlesen der Datei folgendermaßen gestalten damit dir die Zeilenumbrüche in den Werten nicht mehr wehtun:

#include <Array.au3>

$aCSV1 = StringRegExp(FileRead('results-0.csv'), '(?m)^(?>"(?>[^"]++|"")*+"|[^"\v]*)*+$', 3)

_ArrayDisplay($aCSV1)

Zeilenumbrüche in Werten sind bei CSV erlaubt, wenn der Wert in Anführungszeichen steht.
_FileReadToArray() kann dies nicht (und behauptet ja auch nirgends das csv-Format zu unterstützen).

Daher gibt es spezielle Funktionen zum Einlesen von CSV-Daten, welche auch mit soetwas klarkommen:
>>CSV-UDF<<

Zitat von De Rand Ere

Wenn ich im bereits lauffähigen Script mit "Run" arbeiten möchte, müßte ich also über eine Schleife die Anzahl der ZipAufrufe steuern. Über die Id des Prozesses könnte das bestimmt gehen.

Sehe ich das richtig ?

Exakt so!

Mal ein beispielhafter Grundaufbau hierfür:

; Die Parameter, welche abgearbeitet werden sollen
Global $aParams[] = [4,6,1,4,9,1,9,3,2,6,7,9,10,2,3,6,2,1,7,8,3,7,1,2]

; Anzahl parallel laufender Prozesse
; hierfür wird die Anzahl der CPU-Kerne verwendet (nur vom 1. Prozessor, falls mehrere verbaut wären)
Global Const $N = Int(ObjGet("winmgmts:\\localhost\root\CIMV2").ExecQuery("SELECT NumberOfCores FROM Win32_Processor", "WQL", 0).ItemIndex(0).NumberOfCores)

; Alle Prozess-IDs der laufenden Prozesse in einem Array:
Global $aPIDs[$N]

; Arbeite Jobs ab
Global $iNextParamIndex = 0, $bFertig, $i
Do
    ; Variable, mit deren Hilfe das Ende der Abarbeitung geprüft wird
    $bFertig = True

    ; den nächsten freien Slot suchen, falls einer frei ist
    For $i = 0 To Ubound($aPIDs) - 1

        ; Slot belegt - daher diesen überspringen
        If ProcessExists($aPIDs[$i]) Then
            $bFertig = False
            ContinueLoop
        EndIf

        ; keine weiteren abzuarbeitenden Dinge mehr (alle Parameter abgearbeitet)
        If $iNextParamIndex >= UBound($aParams) Then ContinueLoop

        ; Prozess in diesem Slot starten
        $aPIDs[$i] = _macheWasMitDenInputs($aParams[$iNextParamIndex])
        $bFertig = False

        ; auf nächsten Abarbeitungsparameter setzen
        $iNextParamIndex += 1
    Next

    ; kleine Verschnaufpause für die CPU
    Sleep(100)

; solange bis alle Prozesse abgearbeitet wurden
Until $bFertig


; eine Funktion welche was mit dem jeweiligen Input aus $aParams macht
; muss eine Prozess-ID zurückgeben!
Func _macheWasMitDenInputs($vInput)
    Return Run(StringFormat( _
        '"%s" /c timeout /t %d /nobreak', _
        @ComSpec, $vInput _
    ))
EndFunc

Es gibt eine ziemlich klare Ansage, dass keinerlei Featurerequests oder Bugreports zum Thema Maps zu stellen sind: Autoit documentation

Und das Thema dot Notation wird schon gleich mal ganz ausgespart in der Dokumentation.

Ich gebe einem Ticket welches nun ausgerechnet beide Tabuthemen verbindet daher eine Lebenszeit von unter einer Planck-Zeit.

Edit: Tja schau an - Tickets gibt es dazu also doch. Da scheint die klare Warnung ja doch nicht so klar gewesen zu sein

Keine Lösung - lediglich ein Workaround:

($mX.method)('AutoIt')

Zitat von BugFix

Nutzt hier jemand die Beta und kann sagen, ob das dort gefixed ist?

Mir ist keine Beta bekannt, welche neueren Datums wäre als die derzeitige Produktivversion 3.3.16.1
Es könnten also maximal nicht veröffentlichte Alphas sein wo nur ein paar wenige Zugriff haben.
water könnte einer dieserjenigen sein.

Edit: Tja genauso war es dann wohl auch

Naja script-breaking wäre es ja nicht, da es die Funktion _StringSplit() bisher nicht gibt.
Ich persönlich würde die auch nicht zusammenmischen wollen, da die Trennung was nun gerade wirklich gemacht wird über den Funktionsnamen eher ersichtlich als über einen Parameter ganz hinten.
Aber das ist schlicht Geschmackssache.

Wenn sich jemand aus dem Code eine entsprechende _StringSplit() bauen möchte, kann er das ja machen - der Code ist ja keine Raketentechnik.

Es geht ja auch ausschließlich um eigenen Code, da wir eh keinen Einfluss auf die AutoIt-Funktionen selbst haben.
Von daher hat hier jeder alle Freiheiten.

1. Frage: Wo kommen diese Pfadangaben her? Du musst ja irgendwo definieren welche Ordner bearbeitet werden.

2.

Zitat von De Rand Ere

Dazu nutze ich einen externen Packer über CLI (Command Line Interface) mit "RunWait"

Wenn es nur der Aufruf ist - warum dann RunWait und nicht Run()? Mit letzterem hättest du nämlich deine Parallelität.

3. Wenn hingegen noch hinterher mit AutoIt-Code da an den Ordner weitergearbeitet wird, dann müsstest du dies natürlich entsprechend behandeln.

Eine Möglichkeit wäre wie von dir vorgeschlagen, dass Skript aufzuteilen und die Unteraufgabe einer Ordnerbehandlung als eigenen Prozess auszuführen.
Dort musst du dich halt um die Übergabe der Pfadangaben kümmern und da würde ich dir raten den Weg der Aufrufparameter weiterzugehen. Als Austauschspeicher würden auch Dateien gehen oder direkt ein shared-Memory aber das wird dann zu aufwendig und unübersichtlich und da das Subprogramm ja lediglich die Pfade benötigt, kann man die auch ziemlich problemlos einfach dem Programm übergeben.

Eine weitere Möglichkeit wäre, das Skript in einen Master und einen Slave-Teil einzuteilen.

Ob das derzeit laufende Skript der Master oder ein Slave ist, kann man z.B. über _Singleton lösen oder über einen Aufrufparameter für die Slave-Teile.
Dann braucht man nicht 2 verschiedene Skripte.

Oder du arbeitest ganz normal mit einem einzigen Skript weiter aber rufst die zip.exe halt parallel auf wie oben beschrieben.
Dann lässt du eine Dauerschleife laufen, die für jede Prozess-ID der Run-Aufrufe prüft ob diese schon abgeschlossen wurden und falls ja, dann entsprechend die Restarbeiten hierzu auszuführen.

Wenn das alles Aufgaben sind die vom Kommandozeileninterpreter erledigt werden können (Programm aufrufen, Datei kopieren, Ordner löschen klingt für mich so), dann kannst du das auch alles in einen kombinierten Aufruf packen wobei die einzelnen Subbefehle per & verknüpft werden (von AutoIt aufgerufen musst du hierbei an das @ComSpec denken). Auf die Art kannst du von AutoIt per Run mehrere solche Jobs parallel starten.

Aber wie gesagt: Die Grundfrage für uns wäre eigentlich eher 1.: Wo kommen die Pfadangaben her.

Ja viel mehr als ein kleines Snippet ist es ja nicht.
Fand es dennoch für evtl. nützlich für einige und hatte keinen anderen Ort um es zu veröffentlichen.

Im Grunde ist das nix großes - daher keine extra UDF hierfür.
Worum geht es?: Mit StringRegExp können wir uns die Teile eines Strings zurückgeben, welche einem bestimmten Muster entsprechen. In anderen Sprachen gibt es jedoch noch einen weiteren Ansatz:
Dort kann man Strings anhand von Trennstrings trennen, deren Muster sich aus einem regulären Ausdruck ergibt.
Das kann je nach Anwendungsfall einfacher sein als sich ein Muster zu überlegen welches alles andere definiert.

Im Prinzip funktioniert es wie StringSplit - nur dass man anstatt einem Trennstring eben ein Trenn-Pattern angibt.

Hierfür dient nun folgende Funktion (kann sein dass soetwas schonmal ein anderer gemacht hat):

#include <Array.au3>

$sString = "Hello:world:foo://:bar"
$sPattern = ':(?!\/\/)'

$aSplit = _regex_split($sString, $sPattern)
_ArrayDisplay($aSplit)


; #FUNCTION# ====================================================================================================================
; Name ..........: _regex_split
; Description ...: separates a string of separators described by a regular expression.
;                  The separators are not part of the result strings.
; Syntax ........: _regex_split($sString,  $sSplitPattern)
; Parameters ....: $sString             - string, which should be split
;                  $sSplitPattern       - regular expression which defines the separation pattern.
; Return values .: 1D-Array containing the substrings split based on the separators.
; Author ........: AspirinJunkie
; Modified ......: 2023-03-06
; Example .......: $aSplit = _regex_split("Hello:world:foo://:bar", ':(?!\/\/)')
; ===============================================================================================================================
Func _regex_split($sString, $sSplitPattern)
    ; map to be able to add elements dynamically
    Local $mSubStrings[]

    Local $aCut, $iOffset = 1, $iStart, $nLen
    Do
        ; find next separator
        $aCut = StringRegExp($sString, $sSplitPattern, 1, $iOffset)
        If @error Then ExitLoop

        $iStart = @extended
        $nLen = StringLen($aCut[0])

        ; append substring to result map
        MapAppend($mSubStrings, StringMid($sString, $iOffset, $iStart - $iOffset - $nLen))

        $iOffset = $iStart + $nLen - 1
    Until @error

    ; prepare the return array
    Local $aRet[UBound($mSubStrings) + 1]

    ; transfer all values from the map to the array
    For $i = 0 To UBound($mSubStrings) - 1
        $aRet[$i] = $mSubStrings[$i]
    Next
    ; don't forget the part after the last separator
    $aRet[UBound($aRet) - 1] = StringTrimLeft($sString, $iStart - 1)

    Return $aRet
EndFunc

Am besten ist es wohl, wenn du entsprechende Helfertools wie z.B. regex101.com verwendest.

Ich kenne die js-Funktion split in dem Zusammenhang nicht, vermute aber, dass die die Zeichen haben will an denen gematcht wird.
Hierfür wäre mein Vorschlag folgendes Pattern: :(?!\/\/)

Man kann es hingegen auch anders betrachten und anstatt am jeweiligen Match zu splitten einfach alles was nicht Trennzeichen ist matchen.
Hierfür könnte das Pattern dann so aussehen: (?:[^:]+|:(?=\/\/))+

Zitat von hipfzwirgel

Ich hatte keine Ahnung, dass das nur mit den Hex-Zahlen geht. Ich probierte es mit den DEZ zahlen und da kam nur Murks.

Natürlich geht das auch mit Dezimalzahlen.
Die hast du aber nicht genommen. Ich habe die Unicode-Codes der Zeichen angegeben.
Du hingegen hast die ASCII-Codes 124, 47, 45 und 92 verwendet.
Die dezimalen Unicode-Codes für diese Zeichen, welche so nicht im ASCII-Bereich existieren lauten hingegen 9474 (0x2502), 9585 (0x2571), 9472 (0x2500), 9586 (0x2572)

Du hast doch im Kommentar schon die richtigen Unicode-Nummern der Zeichen mit angegeben.
Nur im Code selbst verwendest du hingegen nur die Zeichen aus dem ANSI-Bereich.

Ändere mal deinen Switch-Teil folgendermaßen und verwende unten ChrW() anstatt Chr():

        Switch $i
            Case $i = 1
                $n = 0x2502
            Case $i = 2
                $n = 0x2571
            Case $i = 3
                $n = 0x2500
            Case $i = 4
                $n = 0x2572
            Case $i > 4
                $i = 1
                ContinueLoop
        EndSwitch

Zitat von Moombas

Ich wollte die '3' bei deiner Zeile 24 eben nicht, da ich diese "nicht weiß", sondern über die ID ermitteln und dann den zugehörigen tag .name ausgeben.

Ich weiß. Deshalb habe ich bei der Erstellung der Map die ID als Key verwendet.
Sprich: Wenn du auf das Element mit dem Key "3" zugreifst - erhälst du die Struktur mit der ID=3.

Naja du machst ja eine Bedingungsabfrage.
Willst also die Objekte haben, welche eine bestimmte Eigenschaft besitzen.
Das geht in einem einzelnen AutoIt-Aufruf nicht.

Du könntest eine Funktion schreiben in die deine Schleife verpackt wird und du so die Filterung erreichst.

Oder du nimmst statt einem Array eine Map und verwendest dort als Schlüssel die ID.
Auf die Art kannst du schnell per ID auf die einzelnen structs zugreifen:

Global Const $tagVariables = 'struct;char id[36];char Name[999];endstruct'
Global $Count = 5

Global $mNetworks[] ; leere Map

For $i = 0 To $Count
    Global $tVariable = DllStructCreate($tagVariables)
    With $tVariable
        .id = $i + 1
        .Name = $i +  1 & "_name"
    EndWith
    $mNetworks[$i + 1] = $tVariable
Next

For $Row = 1 to $Count
    With $mNetworks[$Row]
        .id = $Row
        .name = $Row & '_name'
        ConsoleWrite(.id & ': ')
        ConsoleWrite(.name & @CRLF)
    EndWith
Next

Global $A = DllStructGetData($mNetworks[3], "Name")
If @error Then ConsoleWrite("@error: " & @error & @CRLF)
Consolewrite($A & @CRLF)

CBOR ist ein Binärformat, welches beliebig verschachtelte Daten abbilden kann.
Das Prinzip ist im Grunde das gleiche wie bei JSON.
Auch dort kann man direkt seine Variablen aus dem Programm nehmen und in dieses Format konvertieren.
Auf die Art kann man seine Daten außerhalb des Programmes speichern oder mit anderen Programmen austauschen, was umso einfacher ist, da so gut wie alle Programmiersprachen den JSON-Standard verstehen.

Auch bei CBOR ist das ähnlich, nur mit dem Unterschied, dass CBOR eben kein textbasiertes Format ist, sondern ein Binärformat.
Das macht es natürlich unmöglich für einen Menschen es direkt zu lesen aber andererseits sind die Ergebnisse in der Regel kleiner als in JSON.

Nun wie arbeitet man damit? - hier ein Beispiel:

#include "CBOR.au3"

; verschachtelte AutoIt-Struktur erzeugen
Global $aArray = [1, 2.0, 3.3]
Global $vValue[] ; leere Map
    $vValue["Test"] = $aArray
    $vValue[123] = "String"

; AutoIt-Variablen in CBOR-Format binär serialisieren:
$bCBOR = _cbor_encode($vValue)
ConsoleWrite(StringFormat("% 20s: % 8d bytes\n", "serialisierte Größe", BinaryLen($bCBOR)))

; Rückkonvertierung in AutoIt-Variable aus CBOR-Binary:
$vAutoIt = _cbor_decode($bCBOR)

; Testen ob Struktur noch passt:
ConsoleWrite($vAutoIt.Test[2] & @CRLF)

In diesem Fall belegt unsere AutoIt-Datenstruktur am Ende noch 29 Bytes an Platz.

Da der Vergleich zu JSON naheliegt - hier noch ein Beispiel (die JSON-UDF wird noch benötigt) um zu schauen wie beide interagieren:

#include "CBOR.au3"
#include "JSON.au3"

; Daten im JSON-format
Global $sString = '[{"id":"4434156","url":"https://legacy.sky.com/v2/schedules/4434156","title":"468_CORE_1_R.4 Schedule","time_zone":"London","start_at":"2017/08/10 19:00:00 +0100","end_at":null,"notify_user":false,"delete_at_end":false,"executions":[],"recurring_days":[],"actions":[{"type":"run","offset":0}],"next_action_name":"run","next_action_time":"2017/08/10 14:00:00 -0400","user":{"id":"9604","url":"https://legacy.sky.com/v2/users/9604","login_name":"robin@ltree.com","first_name":"Robin","last_name":"John","email":"robin@ltree.com","role":"admin","deleted":false},"region":"EMEA","can_edit":true,"vm_ids":null,"configuration_id":"19019196","configuration_url":"https://legacy.sky.com/v2/configurations/19019196","configuration_name":"468_CORE_1_R.4"},{"id":"4444568","url":"https://legacy.sky.com/v2/schedules/4444568","title":"468_CORE_1_R.4 Schedule","time_zone":"London","start_at":"2017/08/11 12:00:00 +0100","end_at":null,"notify_user":false,"delete_at_end":false,"executions":[],"recurring_days":[],"actions":[{"type":"suspend","offset":0}],"next_action_name":"suspend","next_action_time":"2017/08/11 07:00:00 -0400","user":{"id":"9604","url":"https://legacy.sky.com/v2/users/9604","login_name":"robin@ltree.com","first_name":"Robin","last_name":"John","email":"robin@ltree.com","role":"admin","deleted":false},"region":"EMEA","can_edit":true,"vm_ids":null,"configuration_id":"19019196","configuration_url":"https://legacy.sky.com/v2/configurations/19019196","configuration_name":"468_CORE_1_R.4"}]'
ConsoleWrite(StringFormat("% 20s: % 8d bytes\n", "Größe JSON-String", BinaryLen(StringToBinary($sString, 4))))

; konvertiere in CBOR-Binärdatenformat:
Global $bCBOR = _JsonToCbor($sString)
ConsoleWrite(StringFormat("% 20s: % 8d bytes\n", "Größe CBOR-binary", BinaryLen($bCBOR)))

; wandele in JSON-String zurück um zu schauen ob Hin-und-her Konvertierung korrekt war:
Global $sRecovered = _CborToJson($bCBOR)
ConsoleWrite($sRecovered & @CRLF)

Func _JsonToCbor($sJSONString)
    Local $vData = _JSON_Parse($sString)
    Return _cbor_encode($vData)
EndFunc

Func _CborToJson($bCBOR)
    Local $vDecoded = _cbor_decode($bCBOR)
    Return _JSON_Generate($vDecoded)
EndFunc

Changelog:

Thanks pixelsearch for the clarification!

fee Du verwendest offensichtlich nicht die aktuelle v.3.3.16.1. Der Bug ist bereits bekannt und wurde in Version 3.3.16.1 behoben.

Ist es auch nicht.

Das braucht man nicht künstlich klein zu reden. Wenn Arraydisplay bei einem AutoIt-Keyword abschmiert, dann gehört das gefixt und nicht mit Workarounds umgangen.

Ich selbst kann es gerade nicht testen, aber wenn es sich tatsächlich so wie beschrieben darstellt ist es ein Fall für den >>Issue-Tracker<< (vorher aber mal schauen ob es nicht schon Ticket hierfür gibt)

Hinter $file ist dann ein Anführungszeichen zu viel.

Ausgeben kannst du es so:

$file = "C:\Users\user1\Desktop\59116_zert_asa-ssl_b.pfx"
$pass = 'pass'

$sCommand = "certutil -f -p " & $pass & " -user -importpfx " & $file & " & Pause"

ConsoleWrite($sCommand & @CRLF)

Run($sCommand, "", "", @SW_SHOW)

Certutil ist auch kein Befehl der cmd.exe sondern ein ausführbares Programm.
Daher brauchst du dafür auch kein @comspec