Redirect stderr and stdout from MSDOS promt

Yes

   command.pl >log.txt 2>&1

From the W2K help file, Command reference, filter section (i believe this also works on older DOS after 3.2 psuedo-copied from POSIX/XENIX, but that is partly a guess):

The >& sign redirects the output from one of the default I/O streams (stdout, stdin, stderr) into another. For example, command >output_file 2>&1 redirects any error messages from the processing of command from the screen to the standard file output. The numeric values of the standard outputs are as follows: Standard output Numeric equivalent
Stdin 0
Stdout 1
Stderr 2

K_2K:

works in DOS 3.2+ - no, not even in DOS6.

> was implemented, but no being able to address stdout differently from stderr. IIRC, stdout was redirected, stderr stubbornly went to the screen (DOS 6 machine not feeling well at present, so I can't check...)


qbert220:
And caution....

using ">" alone, without the stream-specifier needs a space before it, since

command ..... filename.xt2>redir

will be interpreted as
command ..... filename.xt 2>redir

not
command ..... filename.xt2 >redir

...Bill

Bill,

Thanks for the correction on my guess, and i would not have written my post during the 4 to 5 minutes while and after yours was up if i knew yours was there and complete.

Qbert,
plz ignore my answer when closing this to PAQ.  I've seen at least one too many questions lately not following EE's guide of "first correct answer gets it unless later answer was absolutely needed to help finish the fix"

Thanks.

2K

2K: We've discussed this phenomenon. No harm done. I'm no demon-typist so it happens to me, too.

Customer's problem resolved. What it's all about..

...Bill

Maybe this will help:  The reserved filename "CON" can be used to copy to the screen in Command Prompt.

I'm running a python script (should be quite similar to how a perl script behaves) and I found out that STDIN redirection won't work, no matter how I write the command line.

STDOUT and STDERR redirection work as expected.

Anyone have a clue on what's going on?

Mauro

As expected using Bill's syntax to get them to and from Python?  or as expected inside Python?  If you want different commands inside your python code to redirect from different files or handles, you should ask a fresh question in the Python or Pearle subject area.


Here's an example of a "hello world" dirivative that asks your name, with "Set /P" looking at STDIN:  You could write this in VBScript, Python, C#, or COBOL, but since we are in the MSDOS subject area, I'll choose that:
:::::::::::::::::::
:: test.cmd
::   test stdin redirection
echo off
setlocal
set zx=
set /p zx=Enter name please:
echo.
echo hello %zx%
:: end of test.cmd
:::::::::::::::::::


Now to use that from DOS in a way that demonstrates DOS STDIN redirection:
:::::::::::::::::::
C:\batch> echo harry > test.txt

C:\batch> test.cmd
Enter name please: tom

hello tom

C:\batch> test.cmd 0<test.txt
Enter name please:
hello harry
:::::::::::::::::::


Note that is all the same no matter which language the program is in, although we could create a pipe instead of using redirection:

:::::::::::::::::::
C:\batch> type test.txt | test.cmd
Enter name please:
hello harry
:::::::::::::::::::


So why bother?
Suppose I wanted the batch itself to default from a setup file, in case you do not answer.  That way the customer can change the default without opening the program:
:::::::::::::::::::
:: test.cmd
::   test stdin redirection
echo off
setlocal
0<test.txt set /p zx=
set /p zx=Enter name please (default %zx%) :
echo.
echo hello %zx%
:: end of test.cmd
:::::::::::::::::::


Now harry only needs to press enter (at least until tom changes the default file):
:::::::::::::::::::
C:\batch> test.cmd
Enter name please (default harry ) :

hello harry

C:\batch> test.cmd
Enter name please (default harry ) : tom

hello tom
:::::::::::::::::::


You should be able to plug your python command lines into a batch wrappper similar to that first set line, with as many different file names and python scripts as you need in one wrapper.


Hope This Helps (\o/),
2K

Hi, thanks for your comments.

I know it could be a different question however I found this thread while searching for good guesses to my problem and thought I'd add a comment here because I felt this really isn't a Python question.

Why? Because with "work as expected" I meant that if I wrote a command line like

C:\> script.py <inputfile >outputfile

I'd expect my script to get whatever is inside "inputfile" (assuming it exists) on the standard input, and to write it standard output into a freshly created (or overwritten) file called "outputfile".

What I get instead is that the script will raise an exception no matter what, lamenting that its input is non-existent.

If I write the script to also parse its command line so that I can write

C:\> script.py inputfile >outputfile

i.e. "inputfile" is an argument, and I let the script open and read the named file, I can in fact test that stdout redirection works (and BTW STDERR redirection also works too).

So my guess was that there could be some quirks in how the Windows command shell does things, and I posted the comment.

Meanwhile, experimenting around, I found out that if I invoke the interpreter explicitly, instead of relying on Windows' shell resolution, i.e.

C:\> python.exe script.py <inputfile >outputfile

then STDIN redirection works, too.

I wonder if this happens with any script interpreter (Perl, TCL, Ruby, etc.) or if it really is Python's fault.