revert im laufenden script.

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.

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.

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.

Zitat von Raeuber_Hotzenplotz

[...] (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

Global $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.

MsgBox(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 Todesschleife

Daher 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.