Dos e / ou versões do Windows do comando Unix SCRIPT

Question

De volta à universidade, quando tivemos que enviar uma tarefa no CS, teríamos que executar uma série de etapas, incluindo a execução de script, date, whoami, etc. e a execução do nosso programa.

O comando script enviaria todo o texto enviado para a exibição tanto para a exibição quanto para um arquivo especificado.

Desde então, tenho procurado uma versão do DOS e / ou do Windows, mas acabei vazia. Alguns programas podem ser redirecionados para um arquivo, mas a exibição não é reproduzida e alguns programas parecem não funcionar com o redirecionamento.

Alguma idéia?

Editar :

Até agora, as respostas que consegui parecem funcionar exatamente como os comandos de redirecionamento padrão ( <, >, | ). Estes não funcionam com todos os programas. Por exemplo, o compilador Microsoft C ++ CL.EXE. Se você executar cl /? através de um comando de redirecionamento ou canalizá-lo através de outro programa (como o TEE), você não obterá o texto do cabeçalho / faixa.

Outro exemplo é um programa que escrevi em Pascal (acho que a última compilação foi no FreePascal). O texto de ajuda não é redirecionado. Eu vi isso acontecer com outros programas, bem como MKISOFS. Ele tem um longo texto de ajuda, mas não pode ser pausado passando por MORE ou redirecionado para um arquivo!

Eu tenho me perguntado sobre isso há muitos anos. Eu costumava pensar que pode ser porque o texto está sendo escrito diretamente na tela (por exemplo, a porta B800) ou algo assim, mas eu ainda tenho que definir a causa, e muito menos encontrar um programa que possa fazer este trabalho.

    

Answer 1

Ok, então, como de costume, decidi escrever o programa. Eu tive um pouco de tempo livre hoje à noite e joguei um programa de teste nativo (ou seja, não-Cygwin) que funciona exatamente como eu esperava, embora com duas limitações. (Eu não tenho um anfitrião sempre ligado, mas vou limpar o programa, escrever documentos e liberá-lo.)

1. Não é possível capturar a saída de programas que gravam diretamente no hardware de vídeo (ou hardware virtualizado conforme o caso), portanto o programa Pascal que mencionei não pode ser capturado a menos que eu o recompile sem o direto flag set - que incidentalmente tornou-se desnecessário quando eu o recompilei com o FreePascal.

2. Não pode receber entrada de stderr . Por exemplo, se você executar cl /? | script.exe c:\test.log , somente o texto de ajuda do compilador da Microsoft será enviado para o arquivo; o banner só será exibido na tela. (Isso é um pouco desconcertante devido à maneira como o programa funciona, então vou investigar isso.)

Há pouco que pode ser feito sobre o problema (1) (eu não ficaria surpreso se houvesse alguma pessoa inteligente em algum lugar que pudesse descobrir uma maneira de interceptar gravações diretas na tela, mas para todas as intenções e propósitos, provavelmente é improvável.)

O problema (2) pode ser contornado redirecionando stderr para stdout antes de canalizá-lo da seguinte maneira. Não é bonito (ou tão conveniente, mas funciona).

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

Também pode / deve ser viável do lado do programa, simplificando assim o pipe, mas ainda não encontrei nenhuma informação sobre como (pelo menos de um modo “normal / oficial”, por exemplo, via C ++). Eu tenho uma idéia sobre como instalar um manipulador de interrupção na tabela de vetores de interrupção para interceptar chamadas para as funções de API de saída comuns, que podem / provavelmente funcionarão. De fato, em 1998, eu escrevi um TSR experimental do DOS (que também funciona no Windows NTVDM), que intercepta funções de saída e as colore (isto é, sintaxe genérica) antes de enviá-las para a tela. Seria / deveria ser fácil adaptá-lo para também enviar uma cópia para um arquivo.

    

Answer 2

Dê uma olhada no Cygwin , ele dá acesso a todas as excelentes ferramentas de linha de comando do UNIX no Windows.

    

Answer 3

Infelizmente, parece que você não terá sorte em encontrar uma solução Microsoft pronta para uso. Você pode verificar um post similar no StackOverflow. O resumo:

• veja a porta Win32 do tee no SourceForge
• use o Cygwin, como Frank Szczerba também menciona
• veja a implementação do tee de Rob van der Woude em um script em lotes do DOS
• mais algumas opiniões

Answer 4

Eu encontrei uma porta Cygwin do comando de script Unix . Ele captura STDOUT e STDERR (para obter a saída do cabeçalho de cl.exe).

No entanto, capturar comandos cmd.exe é um pouco confuso por dois motivos:

• script gera um shell bash cygwin (não cmd.exe)
O script
• não funciona quando iniciado a partir de um shell cmd.exe; deve ser iniciado a partir do cygwin.

Você pode fazer isso:

1. abra um shell do cygwin.
2. script de início
3. inicie um shell cmd.exe dentro do shell cygwin
4. faça suas coisas no cmd.exe
5. sair do cmd.exe
6. sair do script

* também o shell cmd.exe gerado dentro do cygwin é um pouco estranho , mas os comandos parecem funcionar:

• a janela que geralmente aparece se você tentar executar o cl.exe sem executar primeiro o vcvars32.bat não aparece
• a entrada do console é muito complicada (por exemplo, digitar LEFT DIREITO cl ou UP cl não funciona.)

Answer 5

Esta FAQ do General Pascal explica a causa, bem como uma solução para os programas do Turbo Pascal.

Q. When I redirect the screen output of my programs to a file the file is empty and the output still appears on the screen. What am I doing wrong?

A. You are probably using the CRT unit and its default method of writing to stdout is by direct screen writes. In order to enable output to be redirected all writes must be done by DOS. Setting the variable DirectVideo to false has no effect on redirection as all it does is use the BIOS for screen writes - not DOS.

To enable redirection you must not use the CRT unit

OR

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

This will make all output go through DOS and thus can be redirected if desired. To restore the default situation:

AssignCRT(output);
rewrite(output);

    

Answer 6

Muitas alternativas ao CMD facilitam a vida em muitas frentes, incluindo a solução do problema que você indicou no comando de script ausente. Eu usei o PowerCMD e ele redireciona a saída para sua pasta de log por padrão. Então, como usuário final, você verá os comandos enquanto digita e os erros e a saída dos comandos enquanto, simultaneamente, todo o seu trabalho está sendo "registrado" em um arquivo de log.

Para configurá-lo no PowerCMD, vá para Arquivo - > Preferência - > Salvar automaticamente.

Snippet do arquivo de log que está sendo preenchido automaticamente enquanto trabalho no PowerCMD,

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.

    

Answer 7

Isso é realmente duas perguntas em uma, uma para DOS e outra para Windows, embora a resposta seja a mesma para ambas.

Simplesmente não é possível que tal programa exista.

Existem duas variantes básicas de script no Unices e no Linux. Um (como esta versão do Linux ) usa pipes, o outro (como esta versão HP / UX ) usa pseudo-terminais para evitar problemas com programas TUI que apresentam interfaces de "tela cheia" que a abordagem de pipe possui. O Windows NT simplesmente não possui um mecanismo pseudo-terminal. Simplesmente não é possível capture o I / O de e para um console no Windows NT como é com pseudo-terminais em sistemas POSIX. Pode-se usar a abordagem de pipe, mas…

• … o DOS não possui um mecanismo de cano. (Não fique confuso com o que você pode fazer em interpretadores de comandos do DOS. Esses não são pipes.)
• … no Windows NT ele sofrerá com os problemas - da mesma maneira que para a abordagem de pipe no Unices e Linux - que…
  • … alguns programas reconhecerão que sua saída padrão não é um console e age de maneira diferente.
  • … outros programas que tratam o pipe como um console falharão, porque os dispositivos de pipe não suportam as chamadas do sistema específicas do console.

Cygwin confia na cooperação dos programas-alvo em um pretexto coletivo.

Você pode estar se perguntando sobre o comando Cygwin script e por que ele tem o comportamento não muito correto com programas que não são do Cygwin.

O Cygwin tenta emular pseudo-terminais, usando canais do Windows NT. Depende do fato de que todo programa Cygwin usa uma biblioteca de tempo de execução do Cygwin que "sabe" quando um canal é "realmente" um pseudo-terminal, usando informações privadas na biblioteca de tempo de execução do Cygwin e age de acordo. A função isatty() da biblioteca de tempo de execução diz "sim" quando o tempo de execução vê um canal que é "realmente" um pseudo-terminal do Cygwin. Portanto, os programas Cygwin executados pelo script do Cygwin agem como se estivessem conectados a (pseudo-) terminais.

Naturalmente, os programas que não são do Cygwin, que não participam dessa ilusão coletiva, apenas verão os pipes como realmente são, como pipes, e se comportarão como fazem quando suas entradas / saídas / erros padrões são pipes.