5 votes

Commande SCRIPT des versions Dos et/ou Windows de Unix

De retour à l'université, lorsque nous devions soumettre un devoir en informatique, nous devions effectuer une série d'étapes, y compris exécuter script, date, whoami, etc., puis exécuter notre programme.

La commande script permettait de rediriger tout le texte envoyé à l'écran vers à la fois l'écran et un fichier spécifié.

Depuis lors, j'ai cherché une version pour Dos et/ou Windows, mais je n'ai rien trouvé. Certains programmes peuvent être redirigés vers un fichier, mais l'écran n'est alors pas écho et certains programmes ne semblent pas fonctionner du tout avec la redirection.

Des idées ?


Éditer:

Jusqu'à présent, les réponses que j'ai obtenues semblent fonctionner exactement comme les commandes de redirection standard (<, >, |). Ces dernières ne fonctionnent pas avec tous les programmes. Par exemple, le compilateur Microsoft C++ CL.EXE. Si vous exécutez cl /? à travers une commande de redirection ou le faites passer par un autre programme (comme TEE), vous n'obtiendrez pas le texte d'en-tête/bannière.

Un autre exemple est un programme que j'ai écrit il y a un moment en Pascal (je pense que la dernière compilation était en FreePascal). Le texte d'aide n'est pas du tout redirigé. J'ai vu cela se produire également avec d'autres programmes comme MKISOFS. Il a un long texte d'aide, mais ne peut pas être mis en pause en le passant par MORE ou en le redirigeant vers un fichier !

Je me suis posé cette question depuis de nombreuses années. Je pensais autrefois que cela pouvait être dû au fait que le texte est écrit directement sur l'écran (par exemple, le port B800) ou quelque chose du genre, mais je n'ai pas encore trouvé la cause, encore moins trouvé un programme qui peut faire ce travail.

2voto

Chris B-C Points 1031

Jetez un coup d'œil à Cygwin, il vous donne accès à tous ces super outils de ligne de commande UNIX sur Windows.

2voto

Ben Collins Points 11318

D'accord, comme d'habitude, j'ai décidé d'écrire le programme moi-même. J'avais un peu de temps libre ce soir et j'ai rapidement créé un programme de test natif (c'est-à-dire, non-Cygwin) qui fonctionne exactement comme je l'espérais, bien qu'avec deux limitations. (Je n'ai pas un hôte toujours en ligne, mais je vais m'occuper de nettoyer le programme, écrire de la documentation, et le publier.)

  1. Il ne peut pas capturer la sortie des programmes qui écrivent directement sur le matériel vidéo (ou le matériel virtualisé, selon le cas), donc le programme en Pascal dont j'ai parlé ne peut pas être capturé à moins que je le recompile sans le drapeau direct—ce qui est devenu inutile lorsque je l'ai recompilé avec FreePascal.

  2. Il ne peut pas recevoir d'entrée de stderr. Par exemple, si vous exécutez cl /? | script.exe c:\test.log, seul le texte d'aide du compilateur Microsoft sera envoyé au fichier; la bannière ne s'affichera que sur l'écran. (C'est assez déconcertant en raison du fonctionnement du programme, donc je vais enquêter là-dessus.)

Il y a peu à faire concernant le problème (1) (je ne serais pas surpris s'il y avait quelqu'un de malin quelque part qui pourrait trouver un moyen d'intercepter les écritures directes à l'écran, mais pour tous les effets pratiques, c'est probablement peu probable.)

Le problème (2) peut être contourné en redirigeant stderr vers stdout avant de le transmettre comme suit. Ce n'est pas joli (ni aussi pratique, mais ça fonctionne).

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

Il est peut-être/peut être également possible de le régler du côté du programme, simplifiant ainsi le tube, mais je n'ai pas encore trouvé d'informations sur comment le faire (du moins de manière "normale/officielle", par exemple via C++). J'ai une idée d'installer un gestionnaire d'interruption dans la table des vecteurs d'interruption pour intercepter les appels aux fonctions API de sortie courantes, ce qui devrait probablement fonctionner. En fait, en 1998, j'avais écrit un TSR DOS expérimental (qui fonctionne également dans le NTVDM de Windows), qui intercepte les fonctions de sortie et les met en couleur (c'est-à-dire, coloration syntaxique générique) avant de les envoyer à l'écran. Il serait/facile de l'adapter pour également envoyer une copie à un fichier.

entrez la description de l'image ici

1voto

dwestbrook Points 1754

Malheureusement, il semble que vous ne aurez pas de chance de trouver une solution Microsoft prête à l'emploi. Vous pouvez consulter un message similaire sur StackOverflow. Le résumé :

1voto

codinguser Points 251

J'ai trouvé un port Cygwin de la commande Unix script. Il capture à la fois STDOUT et STDERR (il récupère la sortie d'en-tête de cl.exe).

Cependant, la capture des commandes cmd.exe est un peu compliquée pour deux raisons :

  • script lance un shell bash cygwin (pas cmd.exe)
  • script ne fonctionne pas lorsqu'il est lancé à partir d'un shell cmd.exe ; il doit être lancé à partir de cygwin.

Vous pouvez le faire, cependant :

  1. ouvrez un shell cygwin.
  2. démarrez le script
  3. démarrez un shell cmd.exe depuis le shell cygwin
  4. faites ce que vous avez à faire dans cmd.exe
  5. sortez de cmd.exe
  6. sortez du script

*le shell cmd.exe lancé depuis cygwin agit un peu bizarrement, mais les commandes semblent fonctionner :

  • la fenêtre qui s'ouvre habituellement si vous essayez de lancer cl.exe sans avoir d'abord exécuté vcvars32.bat ne s'ouvre pas
  • la saisie de la console est très capricieuse (par exemple, taper GAUCHE DROITE cl ou HAUT cl ne fonctionne pas.)

1voto

codinguser Points 251

Ce FAQ Pascal général explique la cause, ainsi qu'une solution pour les programmes Turbo Pascal.

Q. Lorsque je redirige la sortie de l'écran de mes programmes vers un fichier, le fichier est vide et la sortie apparaît toujours à l'écran. Qu'est-ce que je fais mal?

R. Vous utilisez probablement l'unité CRT et sa méthode par défaut pour écrire sur stdout se fait par des écritures directes à l'écran. Pour permettre la redirection de la sortie, toutes les écritures doivent être faites par DOS. Le réglage de la variable DirectVideo sur faux n'a aucun effet sur la redirection car tout ce qu'il fait est d'utiliser le BIOS pour les écritures à l'écran - et non DOS.

Pour permettre la redirection, vous ne devez pas utiliser l'unité CRT

OU

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

Cela fera passer toute la sortie par DOS et pourra donc être redirigée si désiré. Pour restaurer la situation par défaut:

AssignCRT(output);
rewrite(output);

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X