The attached patch is for sysmodule.c, it contains two changes:

1. The check whether stdin is a directory is rewritten without using
   fstat(), which doesn't exist under CE.

2. Replacing sys.argv[0] with the full path is skipped, CE doesn't have
   a current working dir or paths relative to it, so it must already be an
   absolute path.

The S_ISDIR test is to prevent the case

python < /etc

Is it really possible to invoke Python in such a way on CE? If not, it
would be better if the entire test wasn't performed on CE. If it does
get performed, I think it would be better if the code kept a matching
number of parentheses (i.e. don't incorporate the opening curly bracket
into the conditional).

I don't really know what happens when you try to read()/fread() from
stdin that is a directory, but I guess it will fail quickly even
without an explicit check by Python. A directory can be opened under
win32 just like a file, so I guess that you could also set one as
stdin for a process. All in all, I don't care whether the check is
made or not, but it doesn't hurt to be there either.

I'll submit a changed patch that has the opening curly brackets
outside the conditional code. Thanks for the review, Martin, I
appreciate your support on this.

Changed patch with curly brackets outside the conditional code.

I don't really know what happens when you try to read()/fread() from
stdin that is a directory, but I guess it will fail quickly even
without an explicit check by Python.

Without the explicit check, the interpreter crashed; this was the
reason to add the check in the first place. See bpo-887946.

A directory can be opened under
win32 just like a file, so I guess that you could also set one as
stdin for a process.

I just tried to run

python.exe < c:\python25

on W2k3, and get "Access denied" (instead of getting the error
message of the Python interpreter). Indeed, it is apparently
*not* possible to open a directory just like a file under win32.
As

http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx

explains: you must pass FILE_FLAG_BACKUP_SEMANTICS, which
you normally don't pass.

Not sure whether this all applies to CE, though.

All in all, I don't care whether the check is
made or not, but it doesn't hurt to be there either.

It does hurt. It clutters the code. So if it could be determined
that you can't open a directory at all with CreateFile on
Windows CE, then it would be better if the block was removed,
than fixed.

The CE documentation mentions directories, too, but is silent on the
FILE_FLAG_BACKUP_SEMANTICS use for them. Also, even using that flag, I
can't open a directory under CE. It seems that this check is
superfluous there.

I can also confirm that you get an error if you try to redirect stdin
via the commandline to a dir even before the executable is even
launched. The only way to still have a dir as stdin could be to use
CreateProcess(), but I'm neither sure nor do I care about such abuses.

Do you want to remove the whole check for MS Windows then? Are you
otherwise comfortable with the second part of the patch, the one about
resolving argv[0]?

Do you want to remove the whole check for MS Windows then?

Yes, please. A comment that you can't really redirect from a dir
on Win32 might be useful.

Are you
otherwise comfortable with the second part of the patch, the one about
resolving argv[0]?

That's fine - I trust you that the code is not needed on CE.

Next attempt, exclude all win variants from check.

Thanks for the patch. Committed as r68540, r68541.