Consider the following script, which I want to use as a prototype for a
simple stdin --> stdout filter:

    # foo.py
    import sys

    print "fileno = ", sys.stdin.fileno()

    lines = sys.stdin.xreadlines()
    for line in lines:
        sys.stdout.write(line)

On win32 (Win2k pro, SP3), using ActiveState ActivePython 2.2.1 build 222, I
can execute foo.py either by typing "foo.py" or "python foo.py" on the
command line (the relevant registry key for opening .py files has command
'C:\Python22\python.exe "%1" %*').

If I type "echo bar | foo.py", I get

    C:\>echo bar | foo.py
    The process tried to write to a nonexistent pipe.
    fileno =  -1
    Traceback (most recent call last):
      File "C:\foo.py", line 7, in ?
        lines = sys.stdin.readlines()
    IOError: [Errno 9] Bad file descriptor

whereas if I type "echo bar | python foo.py", I get

    C:\>echo bar | python foo.py
    fileno =  0
    bar

Other tests yield:

    C:\>foo.py < foo.py
    fileno =  -1
    Traceback (most recent call last):
      File "C:\Documents and Settings\Jonathan\My Documents\Programming\Omap
VU\Fast
    CameraDriver\BF_LabView\Leo\foo.py", line 7, in ?
        for line in lines:
    IOError: [Errno 9] Bad file descriptor

    C:\>python foo.py < foo.py
    fileno =  0
    # foo.py
    import sys

    print "fileno = ", sys.stdin.fileno()

    lines = sys.stdin.xreadlines()
    for line in lines:
        sys.stdout.write(line)

If I just type "foo.py" or "python foo.py" on the command line, I get
"fileno = 0" in both cases and the script works identically in both cases.

Can anyone explain what's happening? Why the file descriptor for redirected
stdin has a fileno of -1 if the python script is invoked using "foo.py" but
not when it's invoked with "python foo.py"?

You have bumped into a well-known bug present in many but not all versions
of windows.

A number of versions of windows do not correctly set up for redirected i/o
when a script is run based on running an interpreter selected by automatic
association via the script's file extension. This will affect e.g., perl also.

The workaround is to invoke the interpreter explicitly, as in python foo.py
(as you did) or to put that in a .cmd or .bat file and then use that file
as the executable, and redirect i/o wrt to that. There are also a couple
of tricky ways you can put a single batch command line as the first line
of your python source, and giving it a .cmd extension, and being able to
get the python part interpreted by python and the whole to do redirection ok.
I'm not sure whether/how a .pyc file may get generated and used that way though.
Maybe it works.

There should be a FAQ by now, I would think.

HTH

BR> You have bumped into a well-known bug present in many but not all versions
BR> of windows.

BR> A number of versions of windows do not correctly set up for redirected i/o
BR> when a script is run based on running an interpreter selected by automatic
BR> association via the script's file extension. This will affect e.g., perl also.

BR> The workaround is to invoke the interpreter explicitly, as in python foo.py
BR> (as you did) or to put that in a .cmd or .bat file and then use that file
BR> as the executable, and redirect i/o wrt to that.

PvO> There are also Windows versions where batch files have that same bug!!

E.g. on Windows 98, make a file test1.bat, containing just:
DIR

and then run from a command prompt:
test1 > out

Jonathan