Scrittura dell'output del command in cmd di Windows in un file (con una torsione)

Quindi sto provando a eseguire foo.exe , ma non voglio che l'output al terminal, ma in un file. L'esecuzione di foo.exe > foo.txt dovrebbe farlo per me, ma non lo è. Quando esegue l'exe-file, ottengo l'output. L'exe funziona bene in altre parole. Tuttavia, quando cerco di submit l'output a un file, l'unica cosa che ottengo è questo:

 'c:/Program' is not receachzed as an internal or external command, operable program or batch file. 

Questo viene visualizzato solo quando provo ad inviarlo a un file. Pensando che potrebbe essere il path (che è c:\Program Files (x86)\ e così via) che viene erroneamente interpretato, ho provato a specificare il file di output come così: foo.exe > c:\test.txt , ma ancora no gioia.

Quindi, oltre a affermare che il binario che sto cercando di eseguire è scritto male, c'è qualcosa che posso fare per ovviare a questo? Tieni presente che ottengo un'output valida quando esegui semplicemente l'exe, semplicemente non printing bene a un file. Ovviamente l'output è lì, la domanda è se c'è un modo per prenderlo.

Non hai mostrato il command che stai utilizzando che non riesce. Se lo mostri nella tua domanda, potrebbe essere più facile trovare una soluzione per te.

Mi aspetto che il tuo command sia qualcosa di simile:

C:\> foo.exe|c:\Program Files (x86)\something\test.txt

L'errore che stai ricevendo è in qualche modo un indizio:

'c:/Program' is not receachzed as an internal or external command, operable program or batch file.

Primo:
... is not receachzed as an internal or external command, operable program or batch file.

Ciò si verifica in genere quando si tenta di redirect in un file utilizzando un | invece di un > .

Secondo:
'c:/Program' ...

Quando si specifica un nome di file (o un path) che contiene spazi, è necessario circondarlo in segmenti a quote doppie ( "..." ). Ciò è dovuto al fatto che quando il sistema operativo sta determinando il file da redirect, si arresterà alla ricerca del nome file quando incontra uno spazio non quotato: "c:/Program" .

Prova questo:

 foo.exe>"c:\Program Files (x86)\something\test.txt" 


Se il precedente non funziona per catturare l'output da foo.exe al file di text, allora c'è un'altra possibilità …

Se il programma foo.exe sta scrivendo la sua output a STDERR invece di STDOUT , l'output di foo.exe non verrà catturata utilizzando un semplice reindirizzamento con un singolo > . Dovresti farlo così:

 foo.exe>"c:\Program Files (x86)\something\test.txt" 2>&1 


Edit:

Ecco una spiegazione del reindirizzamento dei file e della notazione 2>&1 .

Quando un programma scrive al terminal, può scrivere su uno di due Streams .

  1. Il stream 1 è indicato come STDOUT o Standard-Output . Tipicamente, i programmi scrivono la loro output "Normale" per il stream 1.

  2. Il stream 2 è definito STDERR o Standard-Error . Tipicamente, i programmi scrivono la loro output "Errore" (errori e messaggi di avviso) al stream 2.

Se un programma scrive una particolare output a STDOUT o STDERR è determinato dal programmatore e come hanno scritto il programma. Alcuni programmi vengono scritti per submit a STDOUT tutte le uscite (output normale e errori).

Quando un programma viene eseguito senza un redirezione di output, tutti gli output normali e di errore vengono inviati allo schermo del terminal senza alcuna distinzione tra ciò che è l'output STDOUT o l'output STDERR .

Quando fai "normale" il reindirizzamento con un singolo > come questo:

 foo.exe > "c:\Program Files (x86)\something\test.txt" 

non stai specificando quale Stream viene reindirizzato al file, quindi assume Stream 1.

È lo stesso che se l'hai digitato come questo:

 foo.exe 1> "c:\Program Files (x86)\something\test.txt" 

Ciò indica l'interpnetworking di command ( cmd.exe ) per acquisire l'output del programma per STDOUT (Stream 1) al nome di file specificato. Il 1 in 1> riferisce a Stream 1.

In questo caso tutto il programma normale viene acquisito nel file, ma se il programma scrive a STDERR (Stream 2), tale output non verrà catturato e verrà mostrato sullo schermo. Questo è in genere il modo "desiderato" per farlo in modo che durante la cattura dell'output normale del programma, è ansible vedere sullo schermo se si verifica un errore.

Se si desidera catturare l'output "normale" a un file e l'output di "Errore" in un file diverso è ansible eseguirlo in questo modo:

  foo.exe > "c:\output.txt" 2> "C:\error.txt" or foo.exe 1> "c:\output.txt" 2> "C:\error.txt" 

Se si desidera che l'output "Normale" e l'output "Errore" siano acquisiti nello stesso file, è ansible specificarlo in questo modo:

 foo.exe > "c:\output.txt" 2>&1 

Questo è fondamentalmente un modo "di stenografia" per specificarlo e significa redirect Stream 1 nel file specificato e anche redirect il Stream 2 allo stesso "luogo" (file) come Stream 1.


Edit:

Pacerier ha chiesto:

Esiste una differenza tra foo.exe> ​​"c: \ output.txt" 2> & 1 e foo.exe> ​​"c: \ output.txt" 2> "c: \ output.txt"? Sono identici?

Breve risposta: Pensi che siano identici, ma no. Sono diversi.

Con il reindirizzamento usando >"filename.ext" , 1>"filename.ext" o 2>"filename.ext" , il > causa l'output di essere scritto in un nuovo file denominato "filename.ext". Se il file "filename.ext" esiste già, verrà prima eliminato.

Quindi, utilizzando:

foo.exe> ​​"c: \ output.txt" 2> "c: \ output.txt"

provoca un "conflitto" in cui entrambi i reindirizzamenti stanno cercando di scrivere allo stesso file e entrambi stanno cercando di eliminare il file se già esiste. Ciò probabilmente provoca un comportmento indesiderato. Generalmente, nessuna delle due uscite NON sarà catturata in modo completo o prevedibile.

Il risultato effettivo dipenderà dal sistema operativo e dalla versione e dipende anche dal command in esecuzione. Ciò che probabilmente accadrà è:

1 L'output inviato a una delle reindirizzamenti verrà catturato o parzialmente acquisito e l'output inviato ad altri reindirizzamenti verrà perso. 2 Il sistema operativo si lamenta del command e nessuna delle uscite verrà acquisita (completamente). 3 Comportmenti non definiti, indesiderati, imprevedibili e inaspettati.

In Windows 7 e probabilmente su Windows Vista / 8/10 e forse su Windows XP, il sistema operativo si lamenta del command e il command verrà annullato.

Ad esempio (Windows 7): ho una cartella denominata "C:\Temp\emptyfolder" e un file denominato "nonexistantfile" non esiste.

 C:\>cd "\Temp\emptyfolder" C:\Temp\emptyfolder>dir nonexistantfile>output.txt File Not Found C:\Temp\emptyfolder>type output.txt Volume in drive F is FFFFx1tb Volume Serial Number is 4011-A5C6 Directory of C:\Temp\emptyfolder C:\Temp\emptyfolder> 

In questo caso, usando un reindirizzamento ( >output.txt ), l'output del command dir viene catturato il file: output.txt e il messaggio di errore File Not Found viene visualizzato sullo schermo … questo è il comportmento previsto .

Adesso, utilizzando entrambi i reindirizzamenti ("> file" e "2" file):

 C:\Temp\emptyfolder>dir nonexistantfile>output.txt 2>output.txt The process cannot access the file because it is being used by another process. C:\Temp\emptyfolder>type output.txt C:\Temp\emptyfolder> 

In questo caso, il sistema operativo si è lamentato del fatto che il file (outout) è già in uso. E il file "output.txt" finisce vuoto (0 byte) e l'output per entrambi i reindirizzamenti è stato perso.

Adesso, infine, utilizzando entrambi i reindirizzamenti ("> file" e "2> & 1"):

 C:\Temp\emptyfolder>dir nonexistantfile>output.txt 2>&1 C:\Temp\emptyfolder>type output.txt Volume in drive C is CCCCCCCC Volume Serial Number is 1234-ABCD Directory of C:\Temp\emptyfolder File Not Found C:\Temp\emptyfolder> 

In questo caso, "> file" causa l'output per "stream 1" ("output standard") da acquisire nel file. E "2> & 1" causa l'output per "stream 2" ("output di errore") da submit attraverso il "stream 1" già reindirizzato e anche essere catturato nel file stesso.

Vale anche la pena notare che l'ordine è importnte. Invertire l'ordine come questo:

 dir nonexistant 2>&1 >output.txt 

non è la stessa e probabilmente non ti darà il risultato desiderato.

In questo caso, "2> & 1", che viene visto e precedentemente eseguito, provoca l'reindirizzamento dell'output "stream 2" ("output di errore") al luogo in cui "stream 1" è attualmente indirizzato a momento, è (per impostazione predefinita) lo schermo. E "> file" causa l'output per "stream 1" ("output standard") da catturare nel file. Il risultato finale è che l'output del command ("stream 1") verrà acquisito nel file, ma l'output di errore ("stream 2") continuerà a passare alla schermata (non al file).