New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
py3k: pythonw.exe fails because std streams a missing #45756
Comments
pythonw.exe fails to run with a runtime error. python.exe works as |
Update: pythonw fails because the standard streams can't be initialized. |
Python 2.6 (svn trunk) doesn't check the file handlers when it creates How should I address the problem in py3k? |
Congratulations Amaury and welcome on board! :) I like to get your opinion on the problem. So far I've figured out that That's going to fix stdin and stdout for non console based programs on |
PATCH:
Guido: |
The new patch fixes the startup problem with pythonw.exe on Windows. I |
Hmm... In internal_close() there's still a test for self->fd >= 0. I'm Also, I don't understand under what circumstances fds < 0 can occur. I |
Guido van Rossum wrote:
I'll check it later. The patch still contains some debugging code that redirects stdout and
It happens when a script is run with pythonw.exe (pyw extension). Here are some links that shed some light on the problem: http://mail.python.org/pipermail/python-dev/2001-January/011423.html The patch creates another problem: Christian |
I made some checks with the vc2005 (msvcr80) runtime library:
Since pythonw (2.5) silently discards any output to stderr, we could --- c:/temp/t 2007-11-12 13:54:34.105463200 +0100
+++ c:/afa/python/py3k/Modules/_fileio.c 2007-11-12 13:52:42.576675100 +0100
@@ -149,6 +149,15 @@
if (PyArg_ParseTupleAndKeywords(args, kwds, "i|si:fileio",
kwlist, &fd, &mode, &closefd)) {
+#ifdef MS_WINDOWS
+ /* Windows sets the descriptor to _NO_CONSOLE_FILENO when */
+ /* the program is run without a console */
+ if (fd == -2)
+ {
+ fd = open("nul", "r+");
+ }
+ else
+#endif
if (fd < 0) {
PyErr_SetString(PyExc_ValueError,
"Negative filedescriptor"); |
The patch is a good idea. However it doesn't work for VS 2003 and MSVCR71: import sys
f = open("stderr.txt", "w")
f.write("stdin: %i\n" % sys.stdin.fileno())
f.write("stdout: %i\n" % sys.stdout.fileno())
f.write("stderr: %i\n" % sys.stderr.fileno())
/me sends another hate letter to Redmond. |
Doh, you're right:
/me needs to get the code of msvcrt7. We could simply check for (fd<0) instead, but it's better to reserve |
IMO you don't need the 'closed' flag and you should continue to test for |
W/o the closed flag it's impossible to distinguish between closed fd and |
I don't understand. When does the difference matter? On Nov 12, 2007 10:14 AM, Christian Heimes <report@bugs.python.org> wrote:
|
Guido van Rossum wrote:
When the check for fd < 0 is removed from fileio_init() there is no way In order to fix the problem with GUI apps on Windows the check for fd < Christian |
I still don't understand. Why do you need to treat a closed fd
I'd suggest that, on Windows, sys.std{in,out.err} should be set to Is there a downside to print/write blowing up right away in apps using pythonw? |
Guido van Rossum wrote:
I don't want to treat the fd differently. I want to return a sensible
But wouldn't that cause a fatal error when sys.stderr is missing and *testing* No, it works: object : Exception('msg',) I've an alternative solution based on Amaurgy's idea. Python could set #ifdef MS_WINDOWS
/* The standard streams of Windows GUI apps aren't connected. */
if (fileno(stdin) < 0) {
if (freopen("NUL", "rb", stdin) == NULL)
Py_FatalError("Py_Initialize: failed to replace stdin");
}
if (fileno(stdout) < 0) {
if (freopen("NUL", "wb", stdout) == NULL)
Py_FatalError("Py_Initialize: failed to replace stdout");
}
if (fileno(stderr) < 0) {
if (freopen("NUL", "wb", stderr) == NULL)
Py_FatalError("Py_Initialize: failed to replace stderr");
}
#endif |
The mail gateway swallows examples: >>> import sys
>>> sys.stderr = None
>>> raise Exception("msg")
>>> del sys.stderr
>>> raise Exception("msg")
object : Exception('msg',)
type : Exception
refcount: 4
address : 0x839d274
lost sys.stderr |
Doesn't sound too important. Anyway, from which call do you want to I'd rather see sys.stdout == None than opening NUL. |
Fixed in r58959 I followed your wish and set sys.stdin, stdout and stderr to None |
I consider the bug fixed and closed. Objections? |
(Sorry, I cannot test just now) |
Since r58962 it doesn't ;) |
Is it the only possibility? On Windows, it is quite common to print to stdout for debugging Prints should work, even if they discard their output. |
As far as I can see print() works if sys.stdout is either None (discard sys.stdout.write() is going to fail when sys.stdout is None but that's class NullWriter:
def write(self, data):
pass
if sys.stdout is None:
sys.stdout = NullWriter() Done ;) |
Ah, I prefer this.
It's not very important indeed. I'm happy with the current behaviour. Let's close this issue. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: