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

4107
Synetech

Als wir in der Universität einen Auftrag in CS einreichen mussten, mussten wir eine Reihe von Schritten durchführen, einschließlich Ausführen script, date, whoami, etc.und dann Ausführen des Programms.

Der scriptBefehl leitet den gesamten an die Anzeige gesendeten Text sowohl an die Anzeige als auch an eine angegebene Datei weiter.

Seitdem habe ich nach einer DOS- und / oder Windows-Version gesucht, bin aber leer gelaufen. Einige Programme können in eine Datei umgeleitet werden, aber die Anzeige wird nicht wiederholt, und einige Programme scheinen überhaupt nicht mit der Umleitung zu arbeiten.

Irgendwelche Ideen?


Bearbeiten :

Bisher scheinen die Antworten, die ich bekommen habe, genau wie die Standardumleitungsbefehle ( <, >, |) zu funktionieren . Diese funktionieren nicht bei allen Programmen. Beispielsweise der Microsoft C ++ - Compiler CL.EXE. Wenn Sie cl /?einen Umleitungsbefehl durchlaufen oder ein anderes Programm (z. B. TEE) durchspielen, wird der Header- / Bannertext nicht angezeigt.

Ein anderes Beispiel ist ein Programm, das ich vor einiger Zeit in Pascal geschrieben habe (ich denke, das letzte Kompilieren war in FreePascal). Der Hilfetext wird überhaupt nicht weitergeleitet. Ich habe gesehen, dass dies auch bei anderen Programmen wie MKISOFS vorkommt. Es hat einen langen Hilfetext, der aber nicht durch Pipe durch MORE oder durch Weiterleiten in eine Datei angehalten werden kann!

Ich habe mich viele Jahre darüber gewundert. Früher dachte ich, es könnte sein, dass der Text direkt auf den Bildschirm geschrieben wird (z. B. Port B800) oder etwas, aber ich muss noch die Ursache festlegen, geschweige denn ein Programm finden, das diese Aufgabe erledigen kann.

5

7 Antworten auf die Frage

2
Frank Szczerba

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

Danke, aber es hat das gleiche Problem, das ich in dem Kommentar zur Antwort von akf erklärt habe. Synetech vor 14 Jahren 0
2
Synetech

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.

(Technisch ist dies eigentlich ein Port von `tee ', nicht von' script ', aber das muss es tun.) Synetech vor 10 Jahren 0
Wenn Sie versuchen, direkte Bildschirmschreibvorgänge abzufangen, treten Kompatibilitätsprobleme auf. Besser kann es sein, ein TSR zu verwenden, das den Bildschirminhalt lesen kann. Ich wette, Screen-Capture-Programme funktionieren. Erfassen Sie die Informationen, nachdem sie geschrieben wurden, und nicht bevor sie geschrieben werden, und Sie werden wahrscheinlich weniger Kompatibilitätsprobleme haben. Ist 20CC verfügbar? Ich finde den grauen Hintergrund abscheulich, aber das Konzept ist faszinierend. Wenn es anpassbar ist (ich muss Quellcode lieben), wäre ich interessiert genug, um eine Kopie zu fangen. Ich habe eine Online-Suche durchgeführt und sie noch nicht gefunden. TOOGAM vor 9 Jahren 0
Wenn Sie den Bildschirm erneut betrachten, sieht er sehr fehlerhaft aus. :( "Größter verfügbarer Hauptspeicher" und "0 Bytes verfügbar zusammenhängend erweitert m"). Wie viele Bytes werden vom "MS-DOS-Benutzer im hohen Speicherbereich" verwendet? Es scheint, als ob einige Bindestriche verschoben wurden. Dies ist passiert zweimal, in beiden Fällen sollten sie unter den Wörtern "Size in Hex" stehen, aber sie sehen so aus, als hätten sie noch mehr Informationen überschrieben. TOOGAM vor 9 Jahren 0
Haben Sie es schon eine Weile benutzt und funktioniert es zuverlässig (keine schwerwiegenden Fehler, die aufgrund von Zeitmangel / Interesse nicht behoben wurden)? Könnten Sie vielleicht Ihre Antwort bearbeiten, um einen Link zum Quellcode des Programms bereitzustellen, falls Sie noch über diesen verfügen? Ich suche das Gleiche (einen Port von `tee '). Agi Hammerthief vor 8 Jahren 0
1
akf

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:

Ich habe sie ausprobiert. Leider funktionieren sie nicht besser als die Standardumleitung. Beispielsweise der MS C ++ - Compiler CL.exe. Wenn Sie cl /?es durch <oder> oder | ausführen oder TEE oder irgendetwas anderes, dann erhalten Sie nur die Ausgabe aus den Optionen, nicht den Kopfzeilentext. Synetech vor 14 Jahren 1
Sie erhalten den Kopfzeilentext wahrscheinlich nicht, da er STDERR gesendet wird. Sie müssen sowohl STDOUT (>) als auch STDERR (2>) umleiten. Ludwig Weinzierl vor 14 Jahren 6
Zu Ihrer Information, so leiten Sie STDERR und STDOUT für cl.exe um: cl /? > output.log 2> & 1 Leftium vor 14 Jahren 3
Keine dieser Weiterleitungen funktioniert (so wie sie ist), weil sie die `exe'-Datei auslöschen würden (ich frage nicht nach einer Umleitung in eine Datei; ich frage nach dem Befehl` `` `` ** '). Sie müssen stattdessen '2> & 1 | `verwenden, um * zu pfeifen *. Synetech vor 12 Jahren 1
1
Leftium

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.)
Danke ** wonsungi **. Schließlich gelang es mir, das Script.exe-Programm von Cygwin zum Laufen zu bekommen, aber ich habe immer noch das gleiche Problem. Ich konnte beide Teile der * CL * -Ausgabe dazu bringen, zu einer Datei mit script.exe oder der oben aufgeführten Umleitungssyntax umzuleiten. Leider gibt es immer noch Programme, die Text auf dem Bildschirm ausgeben und von keinem von diesen weitergeleitet werden. Ein solches Programm ist eine Pascal-App, die ich vor einiger Zeit geschrieben habe (sie druckt mit dem Standard * writeln *). Die aktuelle Version wurde entweder mit Free Pascal oder Turbo Pascal kompiliert. Ich muss beide prüfen und versuchen. Synetech vor 14 Jahren 0
1
Leftium

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); 
Danke für den Link zu den FAQ. Ich habe meine Quellen überprüft und es scheint, dass Sie richtig liegen. Die Version des Programms, das ich verwende, wurde zurückkompiliert, als die CRT-Einheit enthalten war, sodass keine Weiterleitung erfolgt. In der aktuellen Version ist die CRT-Einheit nicht enthalten (in der Tat wird sie auskommentiert, anscheinend, weil ich herausgefunden hatte, dass sie die Ursache des Redir-Problems war, aber vergessen hat). Ich habe die neueste Version kompiliert und getestet, und sie leitet korrekt um. Bei den anderen Apps wie CL scheint es, dass Sie beide richtig waren. Er wird an STDERR weitergeleitet, sodass ich jetzt den Befehl SCRIPT.exe wie erwartet verwenden kann. Vielen Dank. Synetech vor 14 Jahren 0
1
Yazad Khambata

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. 
0
JdeBP

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.

Cygwin ist ein Schritt in die richtige Richtung, aber es gibt andere Eingabeaufforderungen von Drittanbietern, die die erforderliche Funktionalität bereitstellen können. Schließlich müssen Sie nur die Ausgabe an eine Datei und den Bildschirm senden. Da eine Eingabeaufforderung eines Drittanbieters für das Zeichnen des Bildschirms verantwortlich ist, erhält er die Eingabe und kann einfach eine Kopie an eine Datei senden. Das Problem ist, dass dies mit der Standard-Eingabeaufforderung in Windows nicht einfach ist. Wie bei DOS kann es funktionieren, wenn das Programm die Standarddruckfunktionen verwendet (z. B. DOS INT 2F), anstatt direkt auf den Bildschirm zu schreiben. Synetech vor 12 Jahren 0
Kiddo, [eine Eingabeaufforderung ist kein Programm] (http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/a-cli-is-not-a-dos-prompt.html). Ein Befehl _interpreter_ ist ein Programm und [er malt nicht den Bildschirm für andere Programme] (http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/a-command-interpreter-is-not- a-console.html) oder behandeln ihre E / A in irgendeiner Weise. Ihre Vorstellung, dass dies möglich ist, basiert auf einer ziemlich falschen Vorstellung davon, was in Windows funktioniert. Und Sie leben 1986 in Bezug auf DOS. Das sagten die Leute damals, und so geschah es nicht. JdeBP vor 12 Jahren 0
Ich habe versucht, darüber zu streiten. Wenn ich etwas Zeit habe, schreibe ich einfach selbst eine `script.exe`; Ich habe bereits zwei verschiedene Methoden im Auge. Synetech vor 12 Jahren 0