Hallo,
ist es möglich, wenn ich während mein script läuft, (es läuft in einer schleife, die alle 4 std das script wiederholt) die ein oder andere Funktion im Script ändere, es vor der nächsten Wiederholung von selbst den REVERT auszuführt? So dass ohne manuellen Eingriff von mir die Änderungen im nächsten Durchlauf direkt nutzt?
Gruß der Räuber
revert im laufenden script.
-
Raeuber_Hotzenplotz -
16. Januar 2024 um 16:34 -
Unerledigt
-
-
Die Funktionen müssen bereits mit allen gewünschten Varianten ausgestattet sein. Du könntest dann über eine INI zur Laufzeit steuern, welche Teile der Funktion ausgeführt werden.
-
ich weiß nicht, ob ich mich richtig ausgedrückt hatte, wenn ich script habe, wo in einer schleife immer wieder die funktion "datei x nach y verschieben" ausgeführt werden soll, ich dann aber diese Funktion im script an einem anderen Rechner bearbeite (wird durch cloud gesynct), soll am ende der schleife halt immer das script neugeladen werden, damit da die aktuelle version weiter läuft. kann ich das mit dem shortcut Strg+R am ende der schleife bewerkstelligen?
-
Hi,
Zeig mal dein Script, dann weiß man auch um was es geht.
-
Nein, das geht so nicht. Solange die Datei als Programm ausgeführt wird, kann sie nicht verändert werden. Dein Cloudsync kann das auch nicht und wird die Änderung erst aufs Zielsystem kopieren, wenn das Programm nicht mehr läuft.
Die einzige einfache Lösung wäre das Programm extern alle 4 Stunden zu starten. Entweder mit dem Windows Task Scheduler, oder mit einem zweiten anderen Programm.
Dann wäre die Datei nur kurz gesperrt, während das Programm ausgeführt wird und danach direkt wieder freigegeben um verändert zu werden.
-
Code
Alles anzeigentest() func test() while 1 ConsoleWrite("! " & "TEST" & @LF) sleep(2000) ConsoleWrite("> " & "TEST" & @LF) sleep(2000) Send("^R") wend EndFunc
an einem anderen Rechner versuche ich jetzt die Farbe des Textes zu ändern. Damit die Änderung greift, müsste ich mich dann am "server" wo das script läuft einloggen und es neustarten, das würde ich gerne mit dem STRG+R was ja bei scite für Revert steht umgehen.
-
Danke, das habe ich mir fast schon gedacht, und ja stimmt, total vergessen, dass der sync nicht geht, weil die Datei ja in Benutzung ist
-
Im engl. Forum wurde das Thema schon mehrfach diskutiert.
Eine Lösung findest Du hier. -
Ich glaube, ich verstehe noch nicht ganz, wie dein Skript uns unterstützen soll. 😄 Aber wenn ich es richtig auffasse, läuft deine Anwendung auf einem Server und du möchtest, dass das Skript ohne Neustart andere Aktionen ausführen kann, wie zum Beispiel den Text in einer anderen Farbe anzeigen, richtig?
Das Ändern einer INI-Datei sollte tatsächlich jederzeit möglich sein. Das eigentliche Problem liegt wohl eher darin, den Code so zu gestalten, dass er solche Änderungen auch während des Betriebs übernehmen kann.
Meistens bedeutet das, dass du eventuell einen Mechanismus implementieren musst, der auf Änderungen in der Konfigurationsdatei reagiert und entsprechend reagiert.
Das kann beispielsweise ein Listener sein, der die INI-Datei periodisch auf Änderungen überprüft, oder ein Signal, das an das Skript gesendet wird, wenn eine Änderung vorgenommen wird.
So könnte das Skript Anpassungen vornehmen, ohne neu gestartet werden zu müssen.Ich verstehe nicht was du mit den Synchronisieren der Dateien möchtest ?
sind das große Dateien und Wie lange dauert den eine Synchronisieren bei dir im schnitt?
Du könntest aufs Ersteller Datum/Uhrzeit prüfen und erst wenn Datei ca. 3h exzitiert dann schiebe sie rüber. Oder ist da ein anderes Problem, ich muss dazu sagen ich nutze keine Clouddienste. -
Bei mir läuft ein Programm xy.exe. Dieses prüft alle 2 Sekunden ob es eine xy.exe.update.exe gibt. falls ja, dann wird xy.exe in xy.exe.old.exe kopiert, xy.exe beendet, xy.exe.update.exe in xy.exe umbenannt und gestartet. Das läuft bei mir über eine aufgerufene Batch-Datei und läuft problemlos, auch wenn es kompliziert klingt.
-
Je nachdem was für Änderungen im Skript vorgenommen werden sollen, ist entweder funkey's Lösung der richtige Weg (komplette Teile des Skriptes müssen ausgetauscht werden) oder halt die Ini-Datei (nur Parameter mpssen geändert werden) oder sogar beides.
Bzgl. der Ini-Datei, würde ich sie halt bei jedem Funktionsaufruf einlesen, sofern die Anzahl der dort hinterlegten Parameter überschaubar ist, ansonsten einfach auf das Änderungsdatum prüfen.
Ein Listener macht meiner Meinung nach in diesem Fall nicht viel Sinn bzw. birgt ggf. die Gefahr das eine Funktion nur zum Teil ausgeführt wurde und es dann später zu Konflikten kommt, wenn man nicht sicherstellt, das diese bis zum Ende durchgelaufen ist und somit korrekt abgeschlossen hat. -
[...] (es läuft in einer schleife, die alle 4 std das script wiederholt) [...]
Solche Sachen mache ich nicht im Programm selbst, sondern rufe das Programm alle 4 Stunden über die Windows Aufgabenplanung auf, wenn's durch ist, beendet es sich.
Dann kann ich (fast) jederzeit das Programm austauschen/updaten. -
starte doch einfach aus deinem Script heraus alle 4 Std. eine au3.
Die kannst du jederzeit anpassen und die wird alle 4 Std. aufgerufen.
Hängt aber alles davon ab, welche Sicherheit hergestellt werden soll, wer Zugriff auf Änderungen haben darf und und und
siehe (At its simplest: AutoIt3.exe myScript.au3 will run a standard AutoIt script 'myScript.au3' with no parameters.)
https://www.autoitscript.com/autoit3/docs/intro/running.htm -
mal als Beispiel, aber auch zur Warnung
AutoIt: Datei die kompiliert wird:
Alles anzeigenGlobal $PfadzurAutoItExe = @AutoItExe ; oder die autoit3.exe einfach in den Scriptordner kopieren und darauf referenzieren Global $PadzumScript = @DesktopDir & '\test.a3x' ; kann eine .au3 Datei sein oder eine compilierte .a3x Datei. SO kann man nicht das Script im Klartext lesen Global $Timer = TimerInit() While 1 Run('"' & $PfadzurAutoItExe & '" "' & $PadzumScript & '"') While TimerDiff($Timer) < 10000 Sleep(1) WEnd $Timer = TimerInit() WEnd Exit
und als zweites ein Script, dass man jederzeit abändern kann, da es immer zum Aufruf geladen wird:
Dies kann eine .au3 oder eine .a3x Datei sein.
Bei zweiter ist die Datei "compiliert" und kann direkt nicht mehr ausgelesen werden.AutoIt: aufzurufendes ScriptMsgBox(64, "MsgBox", 'Diese MsgBox schließt sich automatisch nach 3 Sekunden', 3) Exit
ABER: Ein Wort der Warnung ...
Diese Konstrukte funktionieren einwandfrei, solange man ein paar Dinge beachtet:
- man kann nicht die kompilierte .exe als Wrapper für sein Script aufrufen. ==> ansonsten Todesschleife
- man muss selber aufpassen, dass die Parameter für den Aufruf der Scriptdatei immer korrekt sind ==> ansonsten TodesschleifeDaher würde ich auch für folgendes Konstrukt plädieren:
Ähnlich dem Aufruf von Powershell Scripten einfach die AutoIt3.exe in die Aufgabenplanung packen und als Parameter die Scriptdatei übergeben.
Der Aufruf erfolgt dann in der Aufgabenplanung zeitgesteuert und immer nur 1x.Das dahinterliegende Script kann jederzeit verändert werden. Zur nächsten Laufzeit wird es erneut eingelesen und verarbeitet.
Ohne es geprüft zu haben...
Die AutoIt3.exe wird dabei jedesmal mit einer neuen PID gestartet und kann somit einzeln und auch parallel oder nur überlappend ausgeführt werden.
Die Beendigung eines aufgerufenen Scripts unterliegt ja eh der Hoheit des Programmierers.