nicht angemeldet
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