Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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
add comment

1 Answer

up vote 7 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.

... 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 >.

'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


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"
    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.

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. –  bigbadonk420 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
Well, for some reason it does. –  bigbadonk420 May 3 '13 at 7:33
@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
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. –  bigbadonk420 May 5 '13 at 9:35
add comment

Your Answer


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.