nicht angemeldet
Hallo Christoph,
da läuft ein bißchen was durcheinander... Hier noch einmal der Dialog zwischen Dir und Andreas, der mich zu einer Antwort nötigte:
Für WINDOWS gibt es meines Wissens keine zuverlässige Entsprechung für cron. Man kann in Scripts (PERL, PHP ...) festlegen, wann bzw. unter welchen Bedingungen sie starten sollen, das ist, in sehr grober Annäherung, ein "Ersatz" für cron.
doch, z.B. at für die Kommandozeile. Auch geplante Tasks, warum sollten die nicht zuverlässig sein?
das funktioniert schon ... aber dann mußt du Stapelverarbeitungsdateien (BAT) schreiben oder (mit Win2000 oder WinXP) registry-Einträge, und das Problem dabei ist, daß du selbst mit WinXP nur unter Schwierigkeiten Pipelines darin unterbringen kannst
Damit sagt Andreas, daß es mit den Geplanten Tasks unter Windows eine zuverlässige Entsprechung zu den cronjobs unter Unix gibt. Im "aber" Deiner Antwort machst Du einige Andeutungen, deren Zweifelhaftigkeit ich mit meinen Fragen anzuzeigen gedachte.
Um die Zitat-folgt-Zitat-Zerfledderung nicht allzuweit voranzutreiben, versuche ich weitestgehend en bloc zu antworten:
Der Interpreter von Shell Scripts (wenn man sie unter Windows so nenne will) ist mitnichten command.com/cmd.exe, sondern cscript/wscript. Das sind Scripting Engines für den Windows Script Host (WSH), die als COM-Komponenten das IActiveScriptParse-Interface unterstützen. Aufgrund der Definition dieses Interfaces zwischen der Scripting Engine und dem Scripting Environment ist es möglich, neben den seit Win98 im OS integrierten Scripting Engines für VBScript und JScript weitere Scripting Engines als COM-Komponenten für andere Sprachen zu implementieren. Somit ist es möglich, Windows-Systeme mit Perl, REXX, Python et al. zu scripten; gegenüber den beiden erstgenannten sind diese nicht nativ im OS vorhanden, sondern müssen installiert werden.
Daß autoexec.bat und config.sys in Win2k und WinXP weitgehend obsolet sind, spricht nicht gegen die Verwendung von DOS-Batches unter diesen OS (bei meinem alten Arbeitgeber werden mehr als 80.000 vernetzte Win98/NT/2k-Rechner mit DOS-Batches problemlos administriert), deshalb verstehe ich auch in Deinem entsprechenden Hinweis das einschränkende "Aber" nicht.
Der Grund dafür, daß Dir mein Hinweis auf die beiden Scripting-Sprachen nicht "leicht verständlich" ist, wird aus Deiner Antwort ersichtlich:
der Hinweis auf diese beiden "Sprachen" ist mir nicht leicht verständlich, weil meines Wissens beide mit Batch-Dateien nichts zu tun haben. VB-Programme kann man (da sie als EXE kompiliert werden) von der Befehlszeile aus aufrufen, mit JScript geht das nicht ohne weiteres. Allerdings läßt sich als "zwischengeschaltetes Feature" der Scripting host einsetzen
Visual Basic hat mit VBScript [1] etwa soviel zu tun wie Java mit JavaScript; der Verweis auf VB-Programme ist ohne Kontext zu unserem Thema. Der WSH (Windows Scripting Host war die alte, inzwischen aufgegebene Bezeichnung) ist keine "zwischengeschaltetes Feature", sondern der Kern der komponentenbasierten Architektur der zur Systemadministration, der im Verbund mit der jeweiligen Sripting Engine von Microsoft als Substitut für die DOS-Batches vorgesehen wurde. Die grundlegende Architektur ist anders als in Unix-Systemen (was weder gut noch schlecht ist, schlicht ein Faktum), in der Außenwirkung jedoch bezüglich der Batch- oder Skriptabarbeitung identisch [2] - und damit sind wird wieder beim Kern des Themas, ob es unter Windows einen systemeigenen Mechanismus gibt, der dem Unix-Mechanismus "cron ruft Skript auf" entspricht: Ja!
Ist damit die Kombination von geplanten Tasks und Batches/Skripten nicht eine Entsprechung zu der Kombination von crontab und Skripten?
Das kann man so sehen, ja. Aber danach war nicht gefragt.
Danach war vom Initiator des Threads nicht explizit gefragt, aber Du stelltes es in Abrede.
HTH Robert
[1] Die zukünftige Unterstützung für VBScript wurde von MS vor einiger Zeit abgekündigt und die Empfehlung für den ausschließlichen Einsatz von JScript an Administratoren und Entwickler ausgesprochen, deshalb hatte ich VBScript als "obsolet" bezeichnet.
[2] Wesentlicher Unterschied ist, daß ich in der Unix Shell in der Kommandozeile des jeweiligen Interpreters stehe und damit interaktiv am Prompt interpretiert werde, während unter Windows keine Interaktion zwischen DOS-Shell und Interpreter stattfindet, sondern nur Skripte filebasiert verarbeitet werden können; durch die native Assoziation zwischen den Endungen .js und .vbs und den zugeordneten Scripting Engines ist keine expliziter Aufruf des Interpreter nötig.