DOS- und / oder Windows-Versionen des Unix-Befehls SCRIPT

Werfen Sie einen Blick auf Cygwin . Hier haben Sie Zugriff auf all diese großartigen UNIX-Befehlszeilen-Tools in Windows.

Okay, wie üblich habe ich es mir selbst überlegt, das Programm zu schreiben. Ich hatte heute Abend etwas Freizeit und warf ein natives (dh nicht von Cygwin) Testprogramm zusammen, das genau wie ich gehofft hatte, allerdings mit zwei Einschränkungen. (Ich habe keinen ständig aktiven Host, aber ich kümmere mich darum, das Programm aufzuräumen, Dokumente zu schreiben und es zu veröffentlichen.)

1. Es kann keine Ausgabe von Programmen erfassen, die direkt auf die Videohardware schreiben (oder ggf. auf virtualisierte Hardware). Daher kann das von mir erwähnte Pascal-Programm nicht erfasst werden, wenn ich es nicht ohne das direkte Flag neu kompiliere es mit FreePascal.

2. Es kann keine Eingaben von stderr empfangen . Wenn Sie beispielsweise ausführen cl /? | script.exe c:\test.log, wird nur der Hilfetext des Microsoft-Compilers an die Datei gesendet. Das Banner wird nur auf dem Bildschirm angezeigt. (Dies ist aufgrund der Funktionsweise des Programms etwas verwirrend. Ich werde es mir genauer ansehen.)

Es gibt wenig, was man mit dem Problem tun kann (1) (Ich wäre nicht überrascht, wenn irgendwo ein kluger Mensch einen Weg finden würde, direkte Bildschirmschreibvorgänge abzufangen, aber in jeder Hinsicht ist dies wahrscheinlich unwahrscheinlich.)

Problem (2) kann durch Umleiten von stderr in stdout vor der Verrohrung wie folgt umgangen werden. Es ist nicht hübsch (oder so bequem, aber es funktioniert).

cl /? 2>&1| script.exe c:\test.log 

Es kann / sollte auch von der Programmseite aus bearbeitbar sein, wodurch die Pipe vereinfacht wird, aber ich habe noch keine Informationen darüber, wie (zumindest auf "normale / offizielle" Weise, z. B. über C ++). Ich habe eine Idee, einen Interrupt-Handler in der Interrupt-Vektortabelle zu installieren, um Aufrufe der API-Funktionen für allgemeine Ausgaben abzufangen, die möglicherweise funktionieren werden. Tatsächlich hatte ich 1998 eine experimentelle DOS-TSR (die auch in Windows NTVDM funktioniert) geschrieben, die Ausgabefunktionen abfängt und sie farbig macht (dh generische Syntaxfärbung), bevor sie an den Bildschirm gesendet werden. Es wäre / wäre einfach, es anzupassen, um auch eine Kopie an eine Datei zu senden.

Leider scheint es so, als hätten Sie kein Glück, eine sofort einsatzbereite Microsoft-Lösung zu finden. Sie können einen ähnlichen Beitrag über StackOverflow auschecken. Die verdauen:

• Schauen Sie sich den Win32-Port von Tee auf SourceForge an
• Verwenden Sie Cygwin, wie auch Frank Szczerba erwähnt
• Sehen Sie sich Rob van der Woudes Abschlag-Implementierung in einem DOS-Stapel-Skript an
• ein paar mehr Meinungen

Ich habe einen Cygwin-Port des Unix-Skriptbefehls gefunden . Es erfasst sowohl STDOUT als auch STDERR (so erhält es die Header-Ausgabe von cl.exe).

Allerdings erfassen cmd.exe Kommandos ist ein wenig verworren aus zwei Gründen:

• Skript erzeugt eine Cygwin-Bash-Shell (nicht cmd.exe)
• Das Skript funktioniert nicht, wenn es von einer cmd.exe-Shell gestartet wird. es muss von cygwin gestartet werden.

Sie können es jedoch tun:

1. Öffnen Sie eine Cygwin-Shell.
2. Skript starten
3. Starten Sie eine cmd.exe-Shell in der cygwin-Shell
4. tun Sie Ihre Sachen in cmd.exe
5. Beenden Sie cmd.exe
6. Beenden Sie das Skript

* Auch die cmd.exe-Shell, die aus Cygwin stammt, wirkt etwas seltsam, aber die Befehle scheinen zu funktionieren:

• Das Fenster, das normalerweise angezeigt wird, wenn Sie versuchen, cl.exe auszuführen, ohne vcvars32.bat auszuführen, wird nicht angezeigt
• Konsoleneingaben sind sehr wählerisch (z. B. funktioniert die Eingabe von LEFT RIGHTcl oder UPcl nicht.)

Diese allgemeine Pascal-FAQ erläutert die Ursache sowie eine Lösung für Turbo Pascal-Programme.

F: Wenn ich die Bildschirmausgabe meiner Programme in eine Datei umleite, ist die Datei leer und die Ausgabe wird weiterhin auf dem Bildschirm angezeigt. Was mache ich falsch?

Antwort: Sie verwenden wahrscheinlich die CRT-Einheit. Die Standardmethode für das Schreiben in stdout ist das direkte Schreiben auf dem Bildschirm. Damit die Ausgabe umgeleitet werden kann, müssen alle Schreibvorgänge von DOS ausgeführt werden. Wenn Sie die Variable DirectVideo auf false setzen, hat dies keine Auswirkungen auf die Umleitung, da das BIOS lediglich für Bildschirmschreibvorgänge verwendet wird - nicht für DOS.

Um die Umleitung zu aktivieren, dürfen Sie die CRT-Einheit nicht verwenden

ODER

assign(output,''); rewrite(output); 

Dadurch wird die gesamte Ausgabe über DOS ausgeführt und kann auf Wunsch umgeleitet werden. So stellen Sie die Standardsituation wieder her:

AssignCRT(output); rewrite(output); 

Viele Alternativen zu CMD erleichtern das Leben in vielen Bereichen, einschließlich der Lösung des Problems, das Sie aufgrund des fehlenden Skriptbefehls angegeben haben. Ich habe PowerCMD verwendet und leitet die Ausgabe standardmäßig in den Protokollordner um. Als Endbenutzer sehen Sie also die Befehle während der Eingabe, die Fehler und die Ausgabe der Befehle, während gleichzeitig Ihre gesamte Arbeit in einer Protokolldatei "protokolliert" wird.

Um es in PowerCMD zu konfigurieren, gehen Sie zu Datei -> Einstellungen -> Automatisch speichern.

Ausschnitt aus der Protokolldatei, die bei der Arbeit mit PowerCMD automatisch aufgefüllt wird,

c:\Software\Microsoft\SysinternalsSuite>date The current date is: Fri 02/13/2015  Enter the new date: (mm-dd-yy)  c:\Software\Microsoft\SysinternalsSuite>someBadCommand 'someBadCommand' is not recognized as an internal or external command, operable program or batch file. 

Dies sind wirklich zwei Fragen in einer, einer für DOS und einer für Windows, obwohl die Antwort für beide gleich ist.

Es ist einfach nicht möglich, dass ein solches Programm existiert.

Es gibt zwei grundlegende Varianten von scriptUnices und Linux. Eine (wie diese Linux-Version ) verwendet Pipes, die andere (wie diese HP / UX-Version ) verwendet Pseudo-Terminals, um Probleme mit TUI-Programmen zu vermeiden, die "Vollbild" -Interfaces aufweisen, die der Pipe-Ansatz aufweist. Windows NT hat einfach keinen Pseudo-Terminal-Mechanismus. Es ist einfach nicht möglich, die E / A zu und von einer Konsole unter Windows NT zu erfassen, wie dies bei Pseudo-Terminals auf POSIX-Systemen der Fall ist. Man könnte den Pipe-Ansatz verwenden, aber…

• … DOS hat keinen Pipe-Mechanismus. (Lassen Sie sich nicht durch das, was Sie mit DOS-Befehlsinterpreter tun können, verwirren. Dies sind keine Pipes.)
• … Unter Windows NT wird es unter den Problemen leiden - ähnlich wie beim Pipe-Ansatz unter Unices und Linux -, dass…
  • … Einige Programme erkennen, dass ihre Standardausgabe keine Konsole ist, und verhalten sich anders.
  • … Andere Programme, die die Pipe wie eine Konsole behandeln, schlagen fehl, weil Pipe-Geräte die konsolen-spezifischen Systemaufrufe nicht unterstützen.

Cygwin setzt auf die Zusammenarbeit der Zielprogramme in einem kollektiven Vorwand.

Sie fragen sich vielleicht, ob der scriptBefehl Cygwin funktioniert und warum er mit nicht-Cygwin-Programmen ein nicht ganz rechtes Verhalten hat.

Cygwin versucht, Pseudo-Terminals mit Windows NT-Pipes zu emulieren. Sie stützt sich auf die Tatsache, dass jedes Cygwin-Programm eine Cygwin-Laufzeitbibliothek verwendet, die "weiß", wann eine Pipe "ein echtes" Pseudo-Terminal ist, die private Informationen für die Cygwin-Laufzeitbibliothek verwendet und entsprechend handelt. Die isatty()Funktion der Laufzeitbibliothek sagt "Ja", wenn die Laufzeit eine Pipe sieht, die "wirklich" ein Cygwin-Pseudo-Terminal ist. Cygwin-Programme, die von Cygwin ausgeführt werden, verhalten sich scriptso, als wären sie mit (Pseudo-) Terminals verbunden.

Natürlich können Nicht-Cygwin-Programme, die nicht an dieser kollektiven Täuschung teilnehmen, die Pipes so sehen, wie sie wirklich sind, als Pipes, und sich so verhalten, wie sie es tun, wenn ihre Standardeingaben / -ausgänge / -fehler Pipes sind.