nicht angemeldet
PHP-Scripte über Cronjobs starten | WinDAU-Frage
Hallo,
ich kenne mich im Bereich CRON-Jobs nicht sonderlich gut aus. Ich weiß was es ist und wozu es gut ist - das wars :-[
Ich möchte gerne einige Scripte die bestimmte Operationen (DB-Backup, Deadletter-Handling, Newsletter Versendung etc.) ausführen über einen Eintrag in die entsprechende CRON-Tab starten.
Meine Frage(n):
-
Können diese Scripte prinzipiell in jeder Scriptsprache - also auch PHP erstellt werden?
-
Wie rufe ich diese Scripte auf?
-
Was passiert, wenn sich ein solches Script mit Fehlermeldung verabschiedet?
-
Gibt es irgendetwas besonderes zu beachten?
Grüße
Axel
-
Moin,
ich kenne mich im Bereich CRON-Jobs nicht sonderlich gut aus. Ich weiß was es ist und wozu es gut ist - das wars :-[
Auch hier die Frage, welches Betriebssystem?
Meine Frage(n):
- Können diese Scripte prinzipiell in jeder Scriptsprache - also auch PHP erstellt werden?
Du meinst das vom Cron aufgerufene Script?
Prinzipiel ja. Es muss nur sichergestellt sein, daß das entsprechende
Environment geladen wird.- Wie rufe ich diese Scripte auf?
Der Cron Job ruft ein shell script auf, welches zunächst das Environment lädt und dann die entsprechende Anwendung.
- Was passiert, wenn sich ein solches Script mit Fehlermeldung verabschiedet?
Entweder du leitest die fehlerausgabe um in ein Log file
programm 2 >> log.file oder es geht per "mail" an root- Gibt es irgendetwas besonderes zu beachten?
Da fällt mir jetzt nichts zu ein.
regds
wiz-
Hi,
Auch hier die Frage, welches Betriebssystem?
Sorry! SUSE Linux x86 (Versionsnummer mom. nicht bekannt - ProviderServer)
Gruß
Axel
-
Moin,
Auch hier die Frage, welches Betriebssystem?
Sorry! SUSE Linux x86 (Versionsnummer mom. nicht bekannt - ProviderServer)
Dann muß ich leider passen. Ich arbeite, unter anderem, mit
HP-Unix. Denoch dürften die Unterschiede, wenn es welche gibt, für
die Cron Jobs nicht all zu groß sein. ( Pure Vermutung )regds
wiz
-
-
Hoi,
- Was passiert, wenn sich ein solches Script mit
Fehlermeldung verabschiedet?
Entweder du leitest die fehlerausgabe um in ein Log file
programm 2 >> log.file oder es geht per "mail" an rootNicht an 'root' :) Nur an den User, dem der Cronjob gehoert.
- Gibt es irgendetwas besonderes zu beachten?
Da fällt mir jetzt nichts zu ein.
Das Environment muss nicht unbedingt vollstaendig sein. Das
gilt IMHO insbesondere fuer Environment-Variablen. (Stichwort
PATH). Auch das PWD ist nicht definiert (sprich, das PWD kann
ueberall im System sein).Gruesse,
CK - Was passiert, wenn sich ein solches Script mit
-
Hallo!
Meine Frage(n):
- Können diese Scripte prinzipiell in jeder Scriptsprache - also auch PHP erstellt werden?
in jeder Sprache, die über die auch Kommandozeile gestartet werden kann
- Wie rufe ich diese Scripte auf?
steht in "man crontab"
- Was passiert, wenn sich ein solches Script mit Fehlermeldung verabschiedet?
Die Ausgabe kann man speichern
- Gibt es irgendetwas besonderes zu beachten?
Erstmal solltest Du wissen ob Du überhaupt Cronjobs verwenden darfst/kannst, wenn der Webserver bei eienem Provider gehostet ist
WINDAU? Willst Du das jetzt unter Unix oder Windows machen?
Grüße
Andreas-
- Gibt es irgendetwas besonderes zu beachten?
Erstmal solltest Du wissen ob Du überhaupt Cronjobs verwenden darfst/kannst, wenn der Webserver bei eienem Provider gehostet ist
Hi,
Ich weiß es und ich darf es :-].
WINDAU? Willst Du das jetzt unter Unix oder Windows machen?
Unter Linux um genau zu sein. Bin nur eigentlich kein Linux-Experte - nutze nur eine Redhat-Standardinstallation als Testserver um bestimmte PHP-Features halbwegs realitätsnah testen zu können.
Gruß
Axel
-
Hallo!
Ich weiß es und ich darf es :-].
Dann gib doch mal einfach in der SHELL oder über SSH
man crontab
und
man 5 crontab
ein. Da steht wie Du das einrichtest. Ich kann das bei mir leider nicht so machen, sondern nur über ein fertiges Webinterface meines Providers. Sagtr der nichts dazu wie Du das machen sollst?
WINDAU? Willst Du das jetzt unter Unix oder Windows machen?
Unter Linux um genau zu sein. Bin nur eigentlich kein Linux-Experte - nutze nur eine Redhat-Standardinstallation als Testserver um bestimmte PHP-Features halbwegs realitätsnah testen zu können.
na dann kannst Du ja auch da nachgucken ;-)
Hab gerade selbst mal geschaut ist ganz hilfreich.Grüße
Andreas-
ein. Da steht wie Du das einrichtest. Ich kann das bei mir leider nicht so machen, sondern nur über ein fertiges Webinterface meines Providers. Sagtr der nichts dazu wie Du das machen sollst?
Hi,
er gibt allgemeine Informationen darüber, wie ein Job eingerichtet wird. Mir ging es aber um eventuelle Sonderfälle im Bereich PHP. Allerdings haben mir die Postings hier schon sehr geholfen. Werde jetzt erstmal ein bissel testen...
Achja... Zugang habe ich über Telnet. PHP ist nicht als Apache-Modul installiert.
Danke!
Gruß
Axel
-
Hallo,
Achja... Zugang habe ich über Telnet.
Sicher? Ueber *telnet*? Wenn ja, dann wuerde ich unweigerlich
den Provider wechseln. Eine Telnet-Verbindung wird ueber eine
ungesicherte Verbindung hergestellt, die Passwoerter, dein
Login und deine saemtlichen Daten kann *jeder* mitlesen, der
gerade zufaellig auf der Lauer liegt.Gruesse,
CK-
Hallo,
Achja... Zugang habe ich über Telnet.
Sicher? Ueber *telnet*? Wenn ja, dann wuerde ich unweigerlich
den Provider wechseln. Eine Telnet-Verbindung wird ueber eine
ungesicherte Verbindung hergestellt, die Passwoerter, dein
Login und deine saemtlichen Daten kann *jeder* mitlesen, der
gerade zufaellig auf der Lauer liegt.Gruesse,
CKHi,
Sorry. "Telnet" ist für mich WinDAU so ein Oberbegriff. Selbstredend verwende ich generell Putty und gehe mittels SSH auf die Maschine. Bitte seht über dieses Fauxpas hinweg ;-]
Gruß
Axel
PS: Dennoch danke für die Hinweise. In der Tat hatte mein Provider bis zum Ende des letzten Jahres _nur_ Telnet
-
-
Hi Axel,
Achja... Zugang habe ich über Telnet.
was Christian sagen wollte ;-): SSH wäre eine Alternative, die bestimmte
Defizite nicht hätte, Dir aber einen gleichwertigen Dialogzugang bieten
würde. ("putty" wäre dazu der Client meiner Wahl.)PHP ist nicht als Apache-Modul installiert.
... was in Deinem Falle hilfreich ist, weil Du es dann über die
Kommandozeile ansprechen kannst. Also: Alle Ampeln auf Grün.Viele Grüße
Michael-
Hallo!
PHP ist nicht als Apache-Modul installiert.
... was in Deinem Falle hilfreich ist, weil Du es dann über die
Kommandozeile ansprechen kannst. Also: Alle Ampeln auf Grün.Das kann ich in der CGI-Version auch!
Grüße
Andreas-
Hi Andreas,
PHP ist nicht als Apache-Modul installiert.
^^^^^
... was in Deinem Falle hilfreich ist, weil Du es dann über die
Kommandozeile ansprechen kannst. Also: Alle Ampeln auf Grün.
Das kann ich in der CGI-Version auch!... Du hast das Wort "nicht" im Posting meines Vorredners
gesehen, ja?Viele Grüße
Michael-
Hallo!
PHP ist nicht als Apache-Modul installiert.
^^^^^
... was in Deinem Falle hilfreich ist, weil Du es dann über die
Kommandozeile ansprechen kannst. Also: Alle Ampeln auf Grün.
Das kann ich in der CGI-Version auch!... Du hast das Wort "nicht" im Posting meines Vorredners
gesehen, ja?Ups ;-) Kann ja mal passieren, hatte mich schon gewundert weil ich es kürzlich genau anders herum gelesen hatte, wäre das also geklärt.
Grüße
Andreas
-
-
-
-
-
- Gibt es irgendetwas besonderes zu beachten?
-
Hallo!
Ich möchte gerne einige Scripte die bestimmte Operationen (DB-Backup, Deadletter-Handling, Newsletter Versendung etc.) ausführen über einen Eintrag in die entsprechende CRON-Tab starten.
Wenn PHP als Modul installiert ist, muß Du ein externes Programm wie Lynx(Textbrowser) oder wget(Offline-Lesen-Download-Tool oder so) benutzen.
- Können diese Scripte prinzipiell in jeder Scriptsprache - also auch PHP erstellt werden?
Ich würde mal sagen ja. Je nach dem mußt Du es über eine Software aufrufen.
- Wie rufe ich diese Scripte auf?
Über 'cronetab -e' kannst Du die cronjobs anlegen. Du mußt rausfinden, welcher Editor dazu verwendet wird, damit Du es auch wieder Abspeichern kannst.
5 Uhr jeden Tag
5 * * * * lynx -dump >/dev/null http://www.domain.de/datenbank.php4
Das /dev/null leitet die Ausgabe ins Nichts. -dump beendet Lynx.
dazu: lynx --helpzu wget: http://groups.google.de/groups?hl=de&lr=&ie=ISO-8859-1&q=crontab+wget&btnG=Google-Suche&meta=group%3Dde.*
Was die Parameter bei wget bedeuten, bekommst Du überwegt --help
raus.
- Was passiert, wenn sich ein solches Script mit Fehlermeldung verabschiedet?
Du kannst die Fehlermeldung, wie schon von einem anderen Poster genannt, umleiten.
Oder das Script so progrmmieren, daß es zu keiner Fehlermeldung kommt.- Gibt es irgendetwas besonderes zu beachten?
Wüßte ich jetzt nicht direkt!
MfG, André Laugks
-
ReHallo!
Ein Link habe ich vergessen:
http://www.dclp-faq.de/q-php-zeitgesteuert.htmlMfG, André Laugks
-
ReHallo!
Ein Link habe ich vergessen:
http://www.dclp-faq.de/q-php-zeitgesteuert.htmlMfG, André Laugks
Hi,
Sehr gut! Danke Dir. Das ist ne Menge Futter. Werde jetzt erstmal testen...
Gruß
Axel
-
Hallo!
Ein Link habe ich vergessen:
http://www.dclp-faq.de/q-php-zeitgesteuert.html#! /usr/local/bin/php -q --
wozu das? kann man dann ei php-script ohne php script.php starten? Wäre ja nicht schlecht!Grüße
Andreas-
Hallo Andreas,
Ein Link habe ich vergessen:
http://www.dclp-faq.de/q-php-zeitgesteuert.html
#! /usr/local/bin/php -q --
wozu das? kann man dann ei php-script ohne php script.php
starten? Wäre ja nicht schlecht!Was meinst du, wofuer die SheBang (die #!-Zeile) sonst da
ist? :) Da wird der Interpreter, der fuer die Datei zustaendig
ist, angegeben. Danach braucht die Datei nur noch
Ausfuehr-Rechte, und schon geht die Luzi ab.Gruesse,
CK-
Holla
Ein Link habe ich vergessen:
http://www.dclp-faq.de/q-php-zeitgesteuert.html
#! /usr/local/bin/php -q --
wozu das? kann man dann ei php-script ohne php script.php
starten? Wäre ja nicht schlecht!Was meinst du, wofuer die SheBang (die #!-Zeile) sonst da
ist? :) Da wird der Interpreter, der fuer die Datei zustaendig
ist, angegeben. Danach braucht die Datei nur noch
Ausfuehr-Rechte, und schon geht die Luzi ab.Und das -q hinten dran bewirkt daß der PHP-Interpreter keinen Header schickt - das macht er sonst nämlich immer, auch wenn man ihn von der Kommandozeile aus aufruft ...
Ciao,
Harry
-
-
-
-
Hi André,
mehr so für's Archiv:
Über 'cronetab -e' kannst Du die cronjobs anlegen.
machen wir ein "crontab" draus.
Du mußt rausfinden, welcher Editor dazu verwendet wird, damit Du es
auch wieder Abspeichern kannst.Eben deshalb mag ich "crontab -e" nicht, was die crontab-Datei
sowohl editiert als auch anschließend aktiviert. Ich mache beides
lieber getrennt:
1. Auslesen mit "crontab -l >datei"
2. Bearbeiten mit dem Editor meiner Wahl
3. Aktivieren mit "crontab datei".5 * * * * lynx -dump >/dev/null http://www.domain.de/datenbank.php4
Das /dev/null leitet die Ausgabe ins Nichts. -dump beendet Lynx.Genau. cron-Jobs haben nämlich gewisse Defizite - oftmals kein
vollständig initialisiertes Environment und auch mit dem stdout
hapert es.- Was passiert, wenn sich ein solches Script mit Fehlermeldung
verabschiedet?
Du kannst die Fehlermeldung, wie schon von einem anderen Poster
genannt, umleiten.
Der Punkt ist: Wenn ein cron-Job Ausgaben nach einem undefinierten
stdout schreibt, dann hält UNIX die Hand drunter und macht eine Mail
an die entsprechende Benutzerkennung draus.
Das kann je nach Szenario hilfreich oder auch ziemlich lästig sein ...Viele Grüße
Michael-
Hallo Michael,
mehr so für's Archiv:
Dito :)
Der Punkt ist: Wenn ein cron-Job Ausgaben nach einem
undefinierten stdout schreibt, dann hält UNIX die Hand
drunter und macht eine Mail an die entsprechende
Benutzerkennung draus.
Das kann je nach Szenario hilfreich oder auch ziemlich
lästig sein ...Richtig. Das hat einen einzigen Grund: man geht davon aus, dass
Ausgaben (egal, ob nach stdout oder stderr) bei Cronjobs einen
Fehler darstellen. Warum sollte ein Cronjob etwas ausgeben? Es
ist schliesslich niemand da, das zu lesen :)Gruesse,
CK-
Hall Christian,
Richtig. Das hat einen einzigen Grund: man geht davon
aus, dass Ausgaben (egal, ob nach stdout oder stderr)
bei Cronjobs einen Fehler darstellen. Warum sollte ein
Cronjob etwas ausgeben? Es ist schliesslich niemand
da, das zu lesen :)ich lasse viele meiner cron-Jobs mails erzeugen und
prüfe "morgens" beim Eintreffen im Büro erst mal, ob
nachts alles wie erwartet gelaufen ist.Für mich wäre also eher das Fehlen der entsprechenden
Mail der Fehlerfall.Viel Spaß beim Forum-Hacken
Michael-
Hallo Michael,
Für mich wäre also eher das Fehlen der entsprechenden
Mail der Fehlerfall.Ja, das ist ein weit verbreitetes Vorgehen. Ich wollte nur
klarstellen, dass das kein Fehlerverhalten ist, sondern dass
das durch aus seine Gruende hat :)Viel Spaß beim Forum-Hacken
*g* Danke
Gruesse,
CK
-
-
-
Hallo!
mehr so für's Archiv:
Über 'cronetab -e' kannst Du die cronjobs anlegen.
machen wir ein "crontab" draus.
Uppps, ich kann mir 'cronetab' nicht abgewöhnen, es ist unglaublich! Ich flippere es jedesmal wieder auf der Konsole ein und bekomme immer wieder die Meldung, cronetab gibt es nicht. ;-)
MfG, André Laugks
- Was passiert, wenn sich ein solches Script mit Fehlermeldung
-
hallo Axel,
Ich möchte gerne einige Scripte die bestimmte Operationen (DB-Backup, Deadletter-Handling, Newsletter Versendung etc.) ausführen über einen Eintrag in die entsprechende CRON-Tab starten.
Können diese Scripte prinzipiell in jeder Scriptsprache - also auch PHP erstellt werden?prinzipiell ja.
- Wie rufe ich diese Scripte auf?
das hängt sehr stark davon ab, was dein Provider zuläßt und welche Art von Zugriff du hast.
- Was passiert, wenn sich ein solches Script mit Fehlermeldung verabschiedet?
es gibt _mindestens_ einen Eintrag im zuständigen log, mit dem man weiterarbeiten und Fehleranalyse betreiben kann.
- Gibt es irgendetwas besonderes zu beachten?
wahrscheinlich. Cronjobs sind auf UNIX(LINUX)-Systemen üblich und für manche Sachen nahezu zwingend erforderlich. Die meisten (und nach meinem Eindruck auch die zuverlässigen) Provider fahren solche Systeme. Es gab mal bei Cygwin ein paar zögerliche Versuche, cron nach Windows zu portieren, mir ist nicht bekannt, daß es das aktuell noch in irgendeiner Form zum download gibt. 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.
Grüße aus Berlin
Christoph S.
-
Hi!
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?
Grüße
Andreas-
hallo Andreas,
Für WINDOWS gibt es meines Wissens keine zuverlässige Entsprechung 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
Grüße retour
Christoph S.
-
Für WINDOWS gibt es meines Wissens keine zuverlässige Entsprechung 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 kannstHallo Christoph,
sind Batches unter Windows nicht das (kastrierte) Analogon zu Shell-Skripten unter Unix? Sind DOS-Batches unter Win2k und WinXP nicht noch genauso einsetzbar wie unter älteren Versionen - gleichwohl sie obsolet sind, da mit JScript (und bis zu dessen Abkündigung VBScript) in diesen OS ein mehr als potenter Ersatz zur Administration verfügbar ist? Ist damit die Kombination von geplanten Tasks und Batches/Skripten nicht eine Entsprechung zu der Kombination von crontab und Skripten?
Sicherlich hast Du recht, daß Pipelining unter Windows weniger Möglichkeiten bietet als unter Unix; aber dann findet man als Entwickler/Admin erforderlichenfalls andere Kopplungs- und Weitergabemechanismen.
HTH Robert
-
hi,
sind Batches unter Windows nicht das (kastrierte) Analogon zu Shell-Skripten unter Unix?
es gibt in der Tat Parallelen. Der "Interpreter" ist bei einer solchen Sichtweise die command.com bzw. in WinXP die cmd.exe, und die "shell" wäre die "Eingabeaufforderung". Allerdings können UNIX-Shells wesentlich mehr als bloß "gestapelte Befehle" abarbeiten, und was du mit "go" ausrichten kannst, ist nicht viel. Shells wie zum Beispiel die bash haben eigentlich alle Möglichkeiten, die auch in den Programmiersprachen zu den Grundlagen zählen: Schleifen, Variablen, Funktionen ... (siehe http://www.selflinux.de/dokumente/Shellprogrammierung04.html)
Sind DOS-Batches unter Win2k und WinXP nicht noch genauso einsetzbar wie unter älteren Versionen
sind sie. Aber Win2000 und WinXP kommen auch schon ohne autoexec.bat und config.sys aus. Dafür gibt es eine autoexec.nt und eine config.nt im Verzeichnis %systemroot%\system32. Und es gibt eine Menge Einstellmöglichkeiten in der registry - wenn man sie denn kennt.
gleichwohl sie obsolet sind, da mit JScript (und bis zu dessen Abkündigung VBScript) in diesen OS ein mehr als potenter Ersatz zur Administration verfügbar ist?
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
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.
Sicherlich hast Du recht, daß Pipelining unter Windows weniger Möglichkeiten bietet als unter Unix; aber dann findet man als Entwickler/Admin erforderlichenfalls andere Kopplungs- und Weitergabemechanismen.
Man findet als Entwickler bzw. Administrator immer einen Weg, sein System so zu "bedienen", daß es die Bedingungen erfüllt, die ihm gestellt werden ;-)
Grüße aus Berlin
Christoph S.
-
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 kannstDamit 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.
-
Moin!
Der Interpreter von Shell Scripts (wenn man sie unter Windows so nenne will) ist mitnichten command.com/cmd.exe, sondern cscript/wscript.
Das stimmt nicht. Die Shell unter MS-DOS ist sehr wohl command.com und cmd.exe ist die unter Windows NT. Das Aequivalent zu Shell Scripts sind dementsprechend .bat bzw. .cmd Dateien. Dass diese mit viel Glueck vielleicht ein hunderstel der Funktionalitaet von Shell Scripts unter Unix bereitsstellen, aendert an der Tatsache nichts. Naja, fuer CMD hat man ja dann endlich mal einiges getan; nahezu unbrauchbar ist es nach wie vor.
Der WSH hat kein direktes Aequivalent in der Unixwelt. Aber seine Systemadministration mit mit VBScript, JScript oder PerlScript auf Basis des WSH zu erledigen ist ungefaehr so, wie wenn man das unter Unix mit einem Perl-Script oder einer anderen Scriptsprache tut. Angesichts der fast nicht vorhandenen Faehigkeiten der Shells unter den Windowsen kann man dazu nur raten.
So long
--
Discovering the usefulness of the "command.com" shell on Windows 9x is left as an exercise to the reader :)
-- from Perl's README.win32 file-
Moin Calocybe!
Der Interpreter von Shell Scripts (wenn man sie unter Windows so nenne will) ist mitnichten command.com/cmd.exe, sondern cscript/wscript.
Das stimmt nicht. Die Shell unter MS-DOS ist sehr wohl command.com und cmd.exe ist die unter Windows NT. Das Aequivalent zu Shell Scripts sind dementsprechend .bat bzw. .cmd Dateien. Dass diese mit viel Glueck vielleicht ein hunderstel der Funktionalitaet von Shell Scripts unter Unix bereitsstellen, aendert an der Tatsache nichts. Naja, fuer CMD hat man ja dann endlich mal einiges getan; nahezu unbrauchbar ist es nach wie vor.
Was stimmt nicht? Du sagst: Die Shell unter MS-DOS ist sehr wohl [...]. Ich habe nicht behauptet, daß dem nicht so wäre. Der Dialog, auf den ich mich bezog, war folgender:
[Robert:] sind Batches unter Windows nicht das (kastrierte) Analogon zu Shell-Skripten unter Unix?
[Christoph:] es gibt in der Tat Parallelen. Der "Interpreter" ist bei einer solchen Sichtweise die command.com bzw. in WinXP die cmd.exe, und die "shell" wäre die "Eingabeaufforderung".Wir sprachen also von Batches (oder Shell-Skripten oder Stapelverarbeitungsprogrammen oder whatever); _diese_ werden cscript interpretiert. Wenn ich also an der Kommandozeile zum Beispiel "foo.js" eintippe und mit Enter abschließe, so wird der _Kommandzeileninterpreter_ diese Eingabe parsen und interpretieren, in der Registry nachschauen, welche Applikation mit der Extension "js" verknüpft ist, und diese Applikation (eben cscript) mit "foo.js" als Parameter aufrufen. cscript wird dann den Inhalt der Skriptdatei interpretieren.
Der WSH hat kein direktes Aequivalent in der Unixwelt. Aber seine Systemadministration mit mit VBScript, JScript oder PerlScript auf Basis des WSH zu erledigen ist ungefaehr so, wie wenn man das unter Unix mit einem Perl-Script oder einer anderen Scriptsprache tut. Angesichts der fast nicht vorhandenen Faehigkeiten der Shells unter den Windowsen kann man dazu nur raten.
Si!
Bye Robert
-
Re!
Der Interpreter von Shell Scripts (wenn man sie unter Windows so nenne will) ist mitnichten command.com/cmd.exe, sondern cscript/wscript.
Das stimmt nicht.
Was stimmt nicht?
Na genau der Satz, den ich da zitiert hatte.
Du sagst: Die Shell unter MS-DOS ist sehr wohl [...]. Ich habe nicht behauptet, daß dem nicht so wäre.
Doch, in eben dem zitierten Satz. Es sei denn, Du meinst mit "Interpreter von Shell Scripts" etwas anderes als die Shell. Das waere dann aber auch falsch. Shell scripts heissen Shell scripts, weil sie von der Shell interpretiert werden.
Der Dialog, auf den ich mich bezog, war folgender:
Den Satz, auf den ich mich bezog, habe ich oben zitiert. ;-)
[Robert:] sind Batches unter Windows nicht das (kastrierte) Analogon zu Shell-Skripten unter Unix?
Ganz genau.
[Christoph:] es gibt in der Tat Parallelen. Der "Interpreter" ist bei einer solchen Sichtweise die command.com bzw. in WinXP die cmd.exe, und die "shell" wäre die "Eingabeaufforderung".
Ebenfalls richtig, wobei noch zu erwaehnen waere, dass die Eingabeaufforderung eben dieses command.com/cmd.exe ist.
Wir sprachen also von Batches (oder Shell-Skripten oder Stapelverarbeitungsprogrammen oder whatever); _diese_ werden cscript interpretiert.
Nein, diese werden von command.com oder cmd.exe, eben der "Shell" interpretiert. Batches sind das MS-DOS-Aequivalent zu Shell scripts. Sogenannte "Windows NT Command Scripts" sind ebenfalls Batchdateien, in denen aber eine erweiterte Syntax verwendet werden kann, die nur CMD.exe versteht, nicht jedoch command.com. In jedem Fall werden sie von der Shell interpretiert und nicht von cscript, welches es uebrigens gar nicht gibt, wenn man nicht zufaellig den WSH installiert hat.
Wenn ich also an der Kommandozeile zum Beispiel "foo.js" eintippe und mit Enter abschließe
foo.js ist *kein* Batch oder Shell script! Batchdateien haben die Endung .bat, oder im Falle von oben genannten Command Scripts auf WinNT auch .cmd. Beliebige andere Scripts, egal in welcher Sprache, werden natuerlich nicht von der Shell interpretiert, aber die sind auch kein Aequivalent zu Shell scripts.
So long
--
Your password must be at least 18770 characters and cannot repeat any of your previous 30689 passwords.
-- http://support.microsoft.com/default.aspx?scid=kb;en-us;Q276304 -
hallo Robert,
Wir sprachen also von Batches
richtig
_diese_ werden cscript interpretiert.
nicht richtig. Ich darf mal zitieren (aus der WINDOWS-Hilfe in WinXP, konkret "ntcmds.chm" im HELP-Verzeichnis):
"Mit Batchdateien, die auch als Batchprogramme (Stapelverarbeitungsprogramme) oder Skripts bezeichnet werden, können Sie Routinetasks oder sich ständig wiederholende Tasks vereinfachen. Eine Batchdatei ist eine nicht formatierte Textdatei, die einen oder mehrere Befehle enthält und die Dateinamenerweiterung .bat oder .cmd hat. Nachdem Sie den Dateinamen an der Eingabeaufforderung eingegeben haben, führt Cmd.exe die Befehle in der Reihenfolge aus, in der sie in der Datei stehen."Wenn ich also an der Kommandozeile zum Beispiel "foo.js" eintippe
dann rufst du eben keine Batchdatei auf, sondern ein Script, das allerdings von cscript interpretiert wird.
Christoph S.
-
-
-
-
-
-
-