Commande SCRIPT des versions Dos et/ou Windows de Unix

De nombreuses alternatives à CMD simplifient la vie à bien des égards, y compris en résolvant le problème que vous avez indiqué de la commande de script manquante. J'ai utilisé PowerCMD et il redirige la sortie vers son dossier de journal par défaut. Ainsi, en tant qu'utilisateur final, vous verrez les commandes telles que vous les tapez et les erreurs et la sortie des commandes tout en enregistrant simultanément tout votre travail dans un fichier journal.

Pour le configurer dans PowerCMD, allez dans Fichier --> Préférences --> Enregistrement automatique.

Extrait du fichier journal qui se remplit automatiquement alors que je travaille sur PowerCMD,

c:\Software\Microsoft\SysinternalsSuite>date
La date actuelle est : ven. 02/13/2015
Entrez la nouvelle date : (mm-jj-aa)
c:\Software\Microsoft\SysinternalsSuite>someBadCommand
'someBadCommand' n'est pas reconnu en tant que commande interne ou externe,
programme exécutable ou fichier de commandes par lots.

C'est vraiment deux questions en une, une pour DOS et une pour Windows, même si la réponse est la même pour les deux.

Il est tout simplement impossible qu'un tel programme existe.

Il existe deux variantes de base de script sur les systèmes Unix et Linux. L'une (comme cette version Linux) utilise des tubes, l'autre (comme cette version HP/UX) utilise des pseudo-terminaux pour éviter les problèmes avec les programmes TUI qui présentent des interfaces en "plein écran" que l'approche des tubes a. Windows NT n'a tout simplement pas de mécanisme de pseudo-terminal. Il est tout simplement impossible de capturer l'E/S vers et depuis une console sur Windows NT comme avec les pseudo-terminaux sur les systèmes POSIX. On pourrait utiliser l'approche des tubes, mais …

• … DOS n'a pas de mécanisme de tube. (Ne vous laissez pas tromper par ce que vous pouvez faire dans les interprètes de commandes DOS. Ce ne sont pas des tubes.)
• … sur Windows NT, cela souffrira des problèmes — très similaires à ceux de l'approche des tubes sur les systèmes Unix et Linux — que …
  • … certains programmes reconnaîtront que leur sortie standard n'est pas une console et agiront différemment.
  • … d'autres programmes qui traitent le tube comme une console échoueront, car les périphériques de tube ne prennent pas en charge les appels système spécifiques à la console.

Cygwin repose sur la coopération des programmes cibles dans une prétention collective.

Vous vous demandez peut-être à propos de la commande script de Cygwin, et pourquoi elle a le comportement pas tout à fait correct avec les programmes non-Cygwin qu'elle a.

Cygwin tente d'émuler des pseudo-terminaux en utilisant des tubes Windows NT. Elle repose sur le fait que chaque programme Cygwin utilise une bibliothèque d'exécution Cygwin qui "sait" quand un tube est "vraiment" un pseudo-terminal, en utilisant des informations privées à la bibliothèque d'exécution Cygwin, et agit en conséquence. La fonction isatty() de la bibliothèque d'exécution dit "oui" quand l'exécution voit un tube qui est "vraiment" un pseudo-terminal Cygwin. Ainsi, les programmes Cygwin exécutés par le script de Cygwin agiront comme s'ils étaient connectés à des (pseudo-)terminaux.

Bien sûr, les programmes non-Cygwin, qui ne participent pas à cette illusion collective, verront simplement les tubes tels qu'ils sont vraiment, comme des tubes, et se comporteront comme ils le font lorsque leurs entrées/sorties/erreurs standard sont des tubes.