1. Dashboard
  2. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
    3. Team
    4. Mitgliedersuche
  3. Forenregeln
  4. Forum
    1. Unerledigte Themen
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Seiten
  • Forum
  • Erweiterte Suche
  1. AutoIt.de - Das deutschsprachige Forum.
  2. Mitglieder
  3. misterspeed

Beiträge von misterspeed

  • BUG ??? File Read nach Script breaking Changes Version 3.3.14.2

    • misterspeed
    • 4. September 2016 um 09:45
    Zitat von Peter S. Taler

    Vielleicht ist auch mein Verständnis von Fileopen usw. nicht richtig. Das Handl gibt es erst mit fileopen. Da ich in fileopen den Pfad sowieso schon festgelegt habe benutze ich den dann auch in den folgenden Befehlen read write usw.

    Rein technisch gesehen wird beim lesen einer Datei immer folgendes getan:

    1. Filehandle erzeugen (open)
    2. Datei einlesen und interpretieren (das open handle gibt hierbei vor welche Codierung genutzt werden soll)
    3. Filehandle löschen (close)

    Fileread mit direkter Pfadangabe ermittelt die Codierung automatisch und erzeugt dann ein passendes fileopen handle. Ein manuelles fileopen ist hier absolut irrelevant, da fileread nichts vom bestehenden handle wissen kann wenn du es nicht explizit übergeben hast.

    Fileread mit handle Angabe erzeugt kein eigenes fileopen handle mehr, weil das ja nicht mehr notwendig ist. Fileread kenn das handle bereits.

    Fileclose akzeptiert im Übrigen nur filehandles und keine Pfadangaben, da das fileclose bereits in fileread/write enthalten ist wenn dort eine Pfadangabe anstelle eines handles genutzt wurde.
    Ein Fileclose ist also nur dann notwendig wenn die filehandles selbst erzeugt wurden. Nutzt man fileread/write nur mit Pfadangaben kann komplett auf fileopen/close verzichtet werden. Allerdings besteht dann eben das Risiko, dass die automatische Codeirungsermittlung Unsinn anstellt, deswegen sollte man meiner Meinung nach grundsätzlich die handles selbst erzeugen und diese an fileread/write übergebn.

  • BUG ??? File Read nach Script breaking Changes Version 3.3.14.2

    • misterspeed
    • 3. September 2016 um 20:59
    Zitat von Peter S. Taler

    @ misterspeed --> Woher weißt Du das? Ich habe einen halben Tag gebraucht um das herauszufinden?

    Steht so in der Hilfe zu fileread(). Ich hab hier im Übrigen noch Autoit 3.3.6.1.


    Zitat von Autoit Hilfe 3.3.6.1


    If a filename is given rather than a file handle - the file will be opened and
    closed during the function call - for parsing large text files this will be much
    slower than using filehandles.
    Note: Do not mix filehandles and filenames,
    i.e., don't FileOpen a file and then use a filename in this function. Use either
    filehandles or filenames in your routines, not both!


    Both ANSI and
    UTF16/UTF8 text formats can be read - AutoIt will automatically determine the
    type.


    A file can be read as binary(byte) data by using FileOpen with the
    binary flag - in this case count is in bytes rather than characters.

    Alles anzeigen


    Wie weiter oben bei den Scriptbreaking Changes erwähnt hat sich scheinbar etwas an der automatischen Inhalts-Erkennung geändert, dadurch liefert fileread() nun ggf. wie bei dir nicht mehr korrekte Ergebnisse wie es zuvor noch der Fall war. Vermutlich wird schlicht ein unpassender fileopen() Mode innerhalb von fileread() verwendet.

  • BUG ??? File Read nach Script breaking Changes Version 3.3.14.2

    • misterspeed
    • 3. September 2016 um 19:39
    Zitat von Peter S. Taler

    wenn ich es richtig verstehe wird '16' öffnen im binary Mode mit der Pfadangabe nicht ausgeführt sondern nur über das Handel

    Fileread mit Pfadangabe beinhaltet immer ein "Systemeigenes" Fileopen. Welcher Fileopen Mode hierbei verwendet wird liegt nicht in deiner Hand. Erzwungene Fileopen Modes sind nur durch die Fileopen-Handle Übergabe an Fileread möglich.

  • InetGet auf verschlüsseltem Bereich

    • misterspeed
    • 21. August 2016 um 19:30
    Zitat von autoBert

    wenn du mit FileZilla Zugriff hast klappt das auch mit der FTPEx.au3.

    Ziemlich sicher sogar, dennoch könnte es diverse Gründe geben warum man hier nicht auf FTP Zugriff via Script setzen kann oder möchte.

    Ein paar Beispiele aus Sicht eines Administrators:

    Sofern es sich um Shared Webspace handelt ist der FTP Zugriff evtl. limitiert (zeitgleiche Zugriffe, Accountanzahl, IP's pro Account usw.). Der Haupt FTP Account für die Administration sollte jedenfalls nicht in einem Script für dritte verwendet werden. Hat man selbst keine Möglichkeit weitere FTP User anzulegen und diese Zugriffstechnisch einzuschränken fällt FTP schonmal weg.

    Ist man selbst unter voller Kontrolle des Hostingservers bleibt noch das Thema Sicherheit. Ich minimiere das Risiko für Angriffe wenn ich nach außen nur das nötigste publiziere, sprich nur meinen Webserver und nicht auch noch andere Dienste wie einen evtl. veralteten und verwundbaren FTP Server (stattdessen FTP nur hinter einer Firewall, per VPN oder aus einem bestimmten IP Bereich erreichbar, welcher eindeutig dem Administrator zuzuordnen ist).

  • Liegen zwei Partitionen auf gleicher Festplatte?

    • misterspeed
    • 13. August 2016 um 08:29

    Das hilft hier garnichts, weil wie Autobert schon bei der Funktion drivegetserial() bemängelte der DOS Befehl vol auch nur die Volume ID und nicht die Datenträger ID zurückgibt. Der Threadersteller möchte aber wissen ob zwei verschiedene Laufwerke (Volumes) auf dem selben physikalischen Datenträger liegen. Das kann man mit dem von mir verlinkten Powershell Script bzw. den darin verwendeten WMI Abfragen ermitteln.

  • Liegen zwei Partitionen auf gleicher Festplatte?

    • misterspeed
    • 11. August 2016 um 20:06

    Hier hat sich jemand ein Powershell Script gebastelt, welches WMI nutzt um eine detailierte Übersicht der Physikalischen Festplatten, deren Partitionierung und Volumes zu erstellen.

    https://www.uvm.edu/~gcd/2013/01/w…that-volume-on/

    Da es sich nur um simple WMI Abfragen handelt kannst du das recht einfach in ein Autoit Script übertragen und alles was du nicht brauchst rauswerfen bzw. deine Rüclgabe entsprechend kürzen/vereinfachen.

  • Autoit TCP server aus Linux heraus erreichen

    • misterspeed
    • 30. Juli 2016 um 20:01

    Vielleicht versendet dein Linux Client die Daten Binär und dein Windows Client als String?

  • Log-in Informationen richtig abspeichern

    • misterspeed
    • 30. April 2016 um 10:21

    Wirklich sicher kann man das nur gestalten, wenn man eine Client/Server Architektur einsetzt und die eigentlich zu schützende Programmfunktion auf einem entfernten Server ohne direkten Benutzerzugriff ausführt. Der Client auf dem Benutzer Rechner dient dann lediglich als Anmeldemaske und sofern vom Server authentifiziert als Steuereinheit. Die Anmeldung kann man dann nicht umgehen, da nur der Server alle relevanten Informationen kennt und nur er alleine entscheidet von wem er sich steuern lässt oder nicht.

    Aber auch hier muss man dann zumindestens die Netzwerkverbindung zwischen Client und Server durch Verschlüsselung absichern um die Anmeldedaten berechtigter Benutzer vor Fremdzugriff zu schützen.

  • Log-in Informationen richtig abspeichern

    • misterspeed
    • 29. April 2016 um 19:26

    So pauschal würd ich das nicht behaupten. Grundsätlzich natürlich richtig was AspirinJunkie schreibt, aber wenn man es nicht richtig umsetzt ist das Passwort bzw. eine Hashkollision trotzdem noch ohne nennenswerten Aufwand erratbar/errechenbar. MD5 ohne Salt wäre jedenfalls nicht die beste Wahl und ohne Passwortrichtlinie die eine Mindestsicherheit vorgibt hilft auch das beste Hashverfahren nichts.

    Ergänzend könntest du die gespeicherten Hashes noch durch Verschlüsselung der Hash-Datei vor fremdem Zugriff schützen. Letztlich kommt man da aber trotzdem noch ran, sofern man ebenfalls Zugriff zum Script hat und dieses dekompilieren kann.

    Eine weitere Maßnahme wäre das Verstecken der Hash-Datei, z.B. durch Speicherung der Daten in der Registry. Mit Quellcode Zugriff und anderen ReverseEngineering Methoden/Tools findet man aber früher oder später trotzdem raus wo und wie die Daten gespeichert werden.

    Alles kombiniert macht es jedenfalls sehr schwer bis unmöglich an die Zugangsdaten zu kommen.

    Das Problem bei dir sehe ich nur darin, dass du scheinbar die Nutzung deines Programmes mit Passwort absichern willst. Wenn ich Zugang zu deinem Programm erhalte und mir so Zugang zum Quellcode verschaffe kann ich die Funktion zur Programmanmeldung einfach deaktivieren. Das macht jedenfalls sehr viel weniger Arbeit als sich damit auseinanderzusetzen wie deine Passwörter generiert und gespeichert werden.

  • Diskpart

    • misterspeed
    • 27. April 2016 um 18:20

    Wir verwenden bei uns diskpart in Verbindung mit dem Script Parameter. Allerdings ist die Kritik/Warnung durchaus berechtigt, solange man keine zuverlässig Methode hat um die richtige "Disk" auszuwählen. Bei uns ist das nicht wirklich problematisch, weil wir das ganze in einer WinPE Umgebung für teilautomatisierte Neuinstallationen verwenden. In den Systemen gibt es daher nur 2 Datenträger (WinPE Boot Stick + lokale Festplatte). Da die lokale Festplatte immer die selbe ID hat brauchen wir hier nichts weiter prüfen. Im schlimmsten Fall könnte sich der Stick aber selbst löschen (z.B. wenn die HDD nicht von der WinPE Umgebung erkannt wird).

    Bei einem System mit produktiver Installation wäre ich jedenfalls ebenfalls sehr vorsichtig mit diskpart. Ein kleiner Fehler und das System ist gelöscht.

  • Hosts Datei

    • misterspeed
    • 16. April 2016 um 22:30
    Zitat von TheGamerTGT

    @Oscar Besser? Oben edited

    Bin zwar nicht Oscar, aber seine Antwort wäre wohl dieselbe. Nein dein Script ist nachwievor fehlerhaft und unsinnig.

    1. Fileopen() zweimal verwendet
    2. Auch fileclose() kann nur mit einem Datei Handle verwendet werden (Hilfe lesen?)
    3. Du hast den Ratschlag von Oscar nicht befolgt und weißt immernoch nicht was fileflush() eigentlich tut, oder aber du hast es schlichtweg nicht verstanden, dass dir diese Funktion rein garnichts bei deinem Vorhaben hilft

    Ich erklär dir daher nun was fileflush() tut. Wie bei allen Schreibvorgängen speichert Windows die zu schreibenden Daten zunächst im schnellen Arbeitsspeicher in einem Schreibpuffer. Dieser wird nur unter bestimmten Umständen entleert, also auf die langsame Festplatte geschrieben (entweder weil der vorgesehen Schreibpuffer voll ist, eine gewisse Zeit keine neuen Daen hinzugekommen sind oder aber das Dateihandle geschlossen wurde). Will man das Schreiben der Daten nun vorzeitig erzwingen um z.B. Datenverlusten vorzubeugen kann man fileflush() verwenden. Fileflush() löscht also nicht den Dateiinhalt wie du fälschlicherweise hier annimmst.

    Obendrein führt dein fileclose() wie erwähnt ohnehin zu einem fileflush(), was dein obiges Script wie gesagt absolut unsinnig macht.

    EDIT:

    Um zur eigentlichen Aufgabe zurückzukommen... welches Ziel verfolgst du mit dem Script? Jeder halbwegs gescheite Virenscanner überwacht heutzutage Veränderungen der Hosts-Datei und verhindert diese normalerweise sogar. Das könnte im Übrigen auch dazu führen, dass deine Versuche die Hosts-Datei per Script zu verändern scheitern werden. Wie dem auch sei... Änderungen der Hosts-Datei sind wohl das kleinste Übel bei einem Virenbefall. Wenn du ernsthaft glaubt einen eigenen Virenschutz mit Autoit realisieren zu können viel Erfolg damit, aber du wirst damit vermutlich nicht sehr weit kommen.

  • Dienst löschen klappt unter Win 10 nicht mehr

    • misterspeed
    • 14. April 2016 um 19:16

    Grundsätzlich würde ich auch mal annehmen, dass man nur als Administrator die ausreichende Berechtigung hat um einen Dienst zu löschen. In deinem Testscript sehe ich allerdings kein #requireadmin

    Um die Fehlerursache herauszufinden wären im Übrigen Debug Outputs aus der betreffenden Funktion nicht verkehrt. Ich tippe aber einfachmal auf fehlende Berechtigung des ausführenden Benutzers.

  • Zufälliger Befehl

    • misterspeed
    • 9. April 2016 um 19:00

    Und wozu braucht man da die Funktion mouseclick()?

    Eine VPN Verbindung kann man anderweitig herstellen und für die Automatisierung von Webseiten gibt es jedemenge sinnvollere Alternativen wie z.B. ie.au3, ff.au3, winhttp.au3

  • Unterschiedliche Antwortzeiten der Anwendung dadurch sporadische Ausführung

    • misterspeed
    • 9. April 2016 um 16:16

    Welche Anwendung soll überhaupt automatisiert werden? Das senden von Tastaturbefehlen und Mausklicks sollte immer die letzte Wahl sein, wenn es wirklich keine Alternative gibt. Viel zuverlässiger arbeiten die "Control*" Funktionen. Außerdem bieten viele Programme Schnittstellen zur Automatisierung (z.B. COM Objekte, API, Kommandozeile). Sollte letzteres vorhanden sein ist das allen anderen Lösungen vorzuziehen, da die Schnittstelle genau hierfür konzipiert wurde, zuverlässig arbeiten sollte und vom Entwickler supportet wird wenn man Fehler findet oder Feature Wünsche hat.

  • Variable deklarieren - isdeclared

    • misterspeed
    • 9. April 2016 um 13:41

    Du weist schon was Funktionen und Funktionsparameter sind? Angenommen du hast eine Funktion in der je nach Benutzereingabe eine variable Pause gemacht werden soll, zusätzlich möchest du einen Default Wert für die Pause haben, wenn vom Benutzer kein manueller Wert festgelegt wurde.

    Das löst man dann einfach über einen Funktionsparameter:

    AutoIt
    $iSleepTime = InputBox("Benutzereingabe","Bitte Pause Zeit in ms definieren")
    if $iSleepTime = "" Then
    	deineFunktion()
    Else
    	deineFunktion($iSleepTime)
    EndIf
    
    
    
    
    Func deineFunktion($iPause=1000)
    	Sleep($iPause)
    	MsgBox(0,"","Die Funktion hat " & $iPause & "ms geschlafen!")
    EndFunc
    Alles anzeigen

    Alles was man in eine separate Datei als Funktionssammlung (UDF) auslagert sollte nach Möglichkeit flexibel und variabel gehalten sein und nicht auf globale Variablen angewiesen sein. Im obigen Beispiel werden alle benötigten Variablen lokal in der Funktion erstellt und genutzt, daher kann die Funktion wie sie ist in beliebige anderen Scripte eingebunden werden ohne sich weiter Gedanken machen zu müssen. Genau so sollten deine Funktionen auch aussehen wenn du sie universal nutzen möchtest.

  • Script frisst nur CPU lasst, das wars. Auf ClientPC funzt es ;) WMI

    • misterspeed
    • 5. April 2016 um 19:04

    Naja dann betreib halt mal ein wenig Debugging. Sprich lass dir nach jeder halbwegs relevanten Codezeile Rückgabewerte und Errorcodes in eine Logdatei schreiben. So kannst du zum einen feststellen bei welcher Funktion das Script überhaupt hängenbleibt und evtl. auch wo der eigentliche Fehler liegt.

    Ich sehe z.B. auf anhieb eine potentielle Ursache für das scheinbar endlos laufende Script. Eine msgbox blockiert, sprich die Ausführung geht erst weiter wenn du diese wegklickst. Wird dein Script nun aber unter einem anderen Benutzerkontext ausgeführt könnte es sein, dass du die msgbox garnicht zu sehen bekommst und dementsprechend auch nicht wegklicken kannst. Bei Scripten die unbeaufsichtigt laufen sollen würde ich Fehler grundsätzlich per Logdateien und ggf. per Emailversandt ausgeben.

  • 2 Dienste, die gegenseitig voneinander abhängig sind - wie Abhängigkeit auflösen? GELÖST

    • misterspeed
    • 3. April 2016 um 19:01

    Würde auch den Starttyp ändern wie hier bereits vorgeschlagen wurde. Unter meiner Win7 Installation stehen beide genannten Dienste auf "manuell" und werden aktuell auch nicht ausgeführt. Desweiteren ist natürlich zu prüfen warum der Starttyp bei dir vom Standard abweicht und ob evtl. Schadsoftware für das Fehlverhalten der Dienste verantwortlich ist.

    Die Integrität der betroffenen Windows Systemdateien kann mit dem CMD Tool "SFC" geprüft bzw. wiedhergestellt werden (Link).

    Ich würde außerdem sämtliche Software welche mit Telefonie und VPN Verbindungen zu tun hat deinstallieren bzw. neuinstallieren. Ein Blick in den Gerätemanager schadet auch nicht. Evtl. gibt es hier ja unbekannte Geräte oder fehlerhaft installierte Gerätetreiber zu finden. Sollte das der Fall sein würde ich aktuelle und passende Treiber beschaffen.

  • Variablen und Pointer

    • misterspeed
    • 3. April 2016 um 17:14

    Betriebsgeheimnis?

    Ähm langsam wirds kindisch. Bin raus hier, da du dein Problem nicht ausreichend und klar genug beschreiben kannst oder willst. Die Lösung bleibt vermutlich auch für immer ein Betriebsgeheimnis der Autoit Gemeinde.

  • (S) Macro für einfachen Ablauf einer Webseite gesucht

    • misterspeed
    • 3. April 2016 um 16:59

    Ich frage mich gerade warum der gute Mann dafür gleich zwei Foren Accounts benötigt.

    https://autoit.de/index.php/User/215044-berlin-brandenburg/

    Warum er mir vor 4 Stunden mit dem zweiten Account eine private Nachricht geschickt hat obwohl er das passende Unterforum für seine Anfrage bereits gefunden hat ist mir auch nicht ganz klar...


    Zitat von berlin-brandenburg


    Hallo misterspeed,
    ich brauche dringend Hilfe.
    Tel. ****************
    Bitte um Rückruf
    Danke
    MfG. Klaus H*****

    Alles anzeigen

    * Persönliche Daten wurden von mir unkenntlich gemacht. ;)


    Wie dem auch sei... ich habe weder Zeit noch Interesse hier eine Lösung beizeusteuern, Geld benötige ich auch keines. Grundsätzlich scheint es aber um die Automatisierung seiner Amazon Verkäuferkonten zu gehen. Jedenfalls spuckt Google zwei seiner Konten aus wenn man nach der Festnetz Telefonnummer sucht. Ob das Forenregelkonform ist und mit den AGB von Amazon vereinbar ist weiß ich nicht.

    Aber vielleicht geht es ja auch um etwas anderes. Wirkliche Informationen hat er ja leider bisher keine bereit gestellt.

  • Variablen und Pointer

    • misterspeed
    • 2. April 2016 um 20:36
    Zitat von teamnoobPDB

    Es handelt sich dabei um eine Lokale Variable und oben im ersten Post hatte ich etwas was ich mir vorgestellt habe


    Nun es ist aber unverständlich was du dir hier vorstellst oder was du überhaupt erreichen willst. Dein Beispiel oben ergibt so jedenfalls keinen Sinn bzw in deinem Beispiel sind überhaupt keine weiteren Maßnahmen notwendig um das gewünschte zu erreichen. Führt man dein obiges Script so aus wie es Autoit vorsieht kommt genau das raus was du haben möchtest:

    AutoIt
    $Variable = 10
    
    
    ; $tmp = _GetPointer($Variable) ; <-- unnötig wird nicht benötigt
    
    
    MsgBox(0, "", $variable); sollte 10 ergeben und ergibt auch 10
    
    
    $Variable = 12
    
    
    MsgBox(0, "", $variable); sollte jetzt 12 ergeben und ergibt auch 12
    
    
    ; Problem: keines ?!
    Alles anzeigen

    Also nochmal:
    Schreibe ein kurzes Beispielscript in dem das Verhalten auftritt, welches du so nicht erwartest. Dann kann man dir auch erklären wie du das in Autoit richtig machst.

    Da du von einer lokalen Variable sprachst schaut dein Script vermutlich so aus:

    AutoIt
    addition(1) ; sollte 1 ergeben und tut es auch
    addition(3) ; sollte nun 4 ergeben, ergibt aber 3
    ; Grund: $variable vergisst seinen Wert beim Verlassen der Funktion und wird bei erneutem Aufruf neu initialisiert mit Wert 0
    
    
    additionstatic(1) ; sollte 1 ergeben und tut es auch
    additionstatic(3) ; sollte nun 4 ergeben und ergibt auch 4
    ; Grund: Durch die static local Deklaration geht der Wert der Variable beim Verlassen der Funktion nicht verloren. Es handelt sich weiterhin nur um eine lokale Variable, welche nur innerhalb der Funktion Gültigkeit hat und nur dort verwendet werden kann.
    
    
    
    
    func addition($value)
       local $variable = 0
       $variable += $value
       msgbox(0,"addition",$variable)
    endfunc
    
    
    func additionstatic($value)
       static local $variable = 0
       $variable += $value
       msgbox(0,"additionstatic",$variable)
    endfunc
    Alles anzeigen

Spenden

Jeder Euro hilft uns, Euch zu helfen.

Download

AutoIt Tutorial
AutoIt Buch
Onlinehilfe
AutoIt Entwickler
  1. Datenschutzerklärung
  2. Impressum
  3. Shoutbox-Archiv
Community-Software: WoltLab Suite™