Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So I'm trying to run foo.exe, but I don't want the output to the terminal but into a file. Running foo.exe > foo.txt should accomplish this for me, but it's not. When I'm running the exe-file, I get the output. The exe is working fine in other words. However, when I try to send the output to a file, the only thing I get is this:

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

This only shows up when I try to send it to a file. Thinking that it could be the path (which is c:\Program Files (x86)\ and so on) which is misinterpreted, I tried specifying the output file like so: foo.exe > c:\test.txt, but still no joy.

So, aside from stating that the binary that I am trying to run is poorly written, is there anything I can do to remedy this? Keep in mind that I do get valid output when simply running the exe, it just won't print nicely to a file. Obviously the output is there, the question is if there is some way to catch it.

share|improve this question
    
What happens if you move the program to a simple directory (C:\Simple or even C:\ ) and try these things from there? – Jan Doggen May 2 '13 at 13:19
up vote 10 down vote accepted

You haven't shown the command you are using that is failing. If you show it in your question, it might be easier to find a solution for you.

I expect your command is something like this:

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

The error you are receiving is somewhat of a clue:

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

First:
... is not recognized as an internal or external command, operable program or batch file.

This typically happens when you try to redirect to a file using a | instead of a >.

Second:
'c:/Program' ...

When specifying a filename (or path) that contains spaces, you must surround it in double-quote marks ("...") . This is because when the OS is determining the file to redirect to, it will stop looking for the filename when it encounters an unquoted space: "c:/Program".

Try this:

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



If the above doesn't work to capture the output from foo.exe to the text file, then there is another possibility...

If the program foo.exe is writing its output to STDERR instead of STDOUT, the output of foo.exe will not be captured by using simple redirection with a single >. You would have to do it like this:

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



Edit:

Here is an explanation of file redirection and the 2>&1 notation.

When a program writes to the terminal, it can write to one of two Streams.

  1. Stream 1 is referred to as STDOUT or Standard-Output. Typically, programs write their "Normal" output to stream 1.

  2. Stream 2 is referred to as STDERR or Standard-Error. Typically, programs write their "Error" output (error and warning messages) to stream 2.

Whether a program writes a particular output to STDOUT or STDERR is determined by the programmer and how they wrote the program. Some programs are written to send all output (normal output and errors) to STDOUT.

When a program is run with no output redirection, all normal and error output is sent to the terminal screen without any distinction between what is STDOUT output or STDERR output.

When you do "normal" redirection with a single > like this:

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

you are not specifying which Stream is being redirected to the file, so Stream 1 is assumed.

It's the same as if you typed it like this:

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

This tells the command interpreter (cmd.exe) to capture the program output for STDOUT (Stream 1) to the specified filename. The 1 in 1> refers to Stream 1.

In this case all the normal program is captured to the file, but if the program writes to STDERR (Stream 2), that output will not be captured and will be shown on the screen. This is generally the "desired" way to do it so that while you are capturing the normal program output, you can see on the screen if an error occurs.

If you want to capture "Normal" output to one file, and "Error" output to a different file you can do it like this:

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

If you want the "Normal" output and the "Error" output to be captured to the same file, you can specify it like this:

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

This is basically a "shorthand" way of specifying it and it means to redirect Stream 1 to the specified file, and to also redirect Stream 2 to the same "place" (file) as Stream 1.


Edit:

Pacerier asked:

Is there any difference between foo.exe > "c:\output.txt" 2>&1 and foo.exe > "c:\output.txt" 2>"c:\output.txt"? Are they identical?

Short answer: You would think they are identical, but no. They are different.

With redirection using >"filename.ext", 1>"filename.ext", or 2>"filename.ext", the > causes the output to be written to a new file named "filename.ext". If the file "filename.ext" already exists, it will be deleted first.

So, using:

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

causes a "conflict" where both redirections are trying to write to the same file and both are trying to delete the file if it already exists. This will likely cause undesired behavior. Generally, one or the other, or both, of the outputs will NOT be captured fully, or predictably.

The actual result will depend on the operating system and version, and may also depend on the command being executed. What will likely happen is:

1 The output sent to one of the redirections will be captured or partially captured, and the output sent to other redirection will be lost. 2 The operating system will complain about the command and neither of the outputs will be captured (fully). 3 Undefined, undesired, unpredictable, unexpected behavior.

On Windows 7 and likely on Windows Vista/8/10, and possibly on Windows XP, the operating system will complain about command and the command will be canceled.

For example (Windows 7): I have a folder named: "C:\Temp\emptyfolder" and a file named "nonexistantfile" doesn't exist there.

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 this case, using one redirection (>output.txt), the output of the dir command is captured the the file: output.txt, and the error message File Not Found is shown on the screen... this is the expected behavior.

Now, using both redirections (">file" AND "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 this case, the operating system complained that the (outout) file is already in use. And the file "output.txt" ends up empty (0 bytes), and the output for both of the redirections was lost.

Now, lastly, using both redirections (">file" AND "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 this case, ">file" causes the output for "stream 1" ("standard output") to be captured to the file. And "2>&1" causes the output for "stream 2" ("error output") to be sent through the already redirected "stream 1", and to also be captured to the (same) file.

It is also worth noting that the order is important. Reversing the order like this:

dir nonexistant 2>&1 >output.txt

is not the same and will probably not give you the desired result.

In this case, "2>&1", which is seen and precessed first, causes the output for "stream 2" ("error output") to be redirected to the place where "stream 1" is currently directed to, which at that moment, is (by default), the screen. And ">file" causes the output for "stream 1" ("standard output") to be captured to the file. The end result, is that the output of the command ("stream 1") will be captured to the file, but the error output ("stream 2"), will still go to the screen (not to the file).

share|improve this answer
    
Turns out that foo.exe>"c:\test.txt" actually worked, but it threw an error that the program crashed (output was still there though). However, your suggestion made it even better as the 2>&1 made the crash complaint go away. Care to elaborate on what it does? Thanks again for a great answer. – pzkpfw May 3 '13 at 5:29
    
@bigbadonk420 - I updated my answer to include information about the use of 2>&1. If you examine your file "c:\test.txt", you will most likely see that the "crash complaint" was written to the file. 2>&1 shouldn't cause or prevent the program from crashing, it just causes the error messages to be captured rather than displayed. – Kevin Fegan May 3 '13 at 7:02
1  
Well, for some reason it does. – pzkpfw May 3 '13 at 7:33
1  
@bigbadonk420 - 'for some reason it does' in what way is it affected by redirection? Are you saying that when you redirect including 2>&1, that the error doesn't occur? What error message are you seeing when the error occurs? – Kevin Fegan May 3 '13 at 16:11
1  
When 2>&1 is not included, the program crashes and I get the standard Windows "this program has stopped responding" dialog. When I do include it, it does not. No idea why. Output is generated in both cases though. – pzkpfw May 5 '13 at 9:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.