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.
Stream 1 is referred to as STDOUT or Standard-Output. Typically, programs write their "Normal" output to stream 1.
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).
