Issue 973507: sys.stdout problems with pythonw.exe (original) (raw)
Created on 2004-06-15 20:34 by manlioperillo, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (8)
Author: Manlio Perillo (manlioperillo)
Date: 2004-06-15 20:34
sys.version '2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]' sys.platform 'win32' sys.getwindowsversion() (5, 1, 2600, 2, '')
Hi. I have written this script for reproducing the bug:
import sys
class teeIO: def init(self, *files): self.__files = files
def write(self, str):
for i in self.__files:
print >> trace, 'writing on %s: %s' % (i, str)
i.write(str)
print >> trace, '-' * 70
def tee(*files): return teeIO(*files)
log = file('log.txt', 'w') err = file('err.txt', 'w') trace = file('trace.txt', 'w')
sys.stdout = tee(log, sys.stdout) sys.stderr = tee(err, sys.stderr)
def write(n, width): sys.stdout.write('x' * width) if n == 1: return
write(n - 1, width)
try: 1/0 except: write(1, 4096)
[output from err.log] Traceback (most recent call last): File "sys.py", line 36, in ? write(1, 4096) File "sys.py", line 28, in write sys.stdout.write('x' * width) File "sys.py", line 10, in write i.write(str) IOError: [Errno 9] Bad file descriptor
TeeIO is needed for actually read the program output, but I don't know if the problem is due to teeIO.
The same problem is present for stderr, as can be seen by swapping sys.stdout and sys.stderr.
As I can see, 4096 is the buffer size for sys.stdout/err. The problem is the same if the data is written in chunks, ad example: write(2, 4096/2).
The bug isn't present if I use python.exe or if I write less than 4096 bytes.
Thanks and regards Manlio Perillo
Author: Tim Peters (tim.peters) *
Date: 2004-06-15 23:09
Logged In: YES user_id=31435
Ya, this is well known, although it may not be documented.
pythonw's purpose in life is not to create (or inherit) a
console window (a "DOS box"). Therefore stdin, stdout, and
stderr aren't attached to anything usable. Microsoft's C
runtime seems to attach them to buffers that aren't
connected to anything, so they complain if you ever exceed
the buffer size.
The short course is that stdin, stdout and stderr are useless in programs without a console window, so you shouldn't use them. Or you should you install your own file-like objects, and make them do something useful to you.
I think it would be helpful if pythonw did something fancier (e.g., pop up a window containing attempted output), but that's in new-feature terrority, and nobody has contributed code for it anyway.
Author: Manlio Perillo (manlioperillo)
Date: 2004-06-16 17:05
Logged In: YES user_id=1054957
The problem with this bug is that I have a script that can be executed both with python.exe that with pythonw.exe! How can I know if stdout is connected to a console?
I think a 'patch' would be to replace sys.stdout/err with a null stream instead of using windows stdout/err implementation. If fileno can't be implemented, it should not be a problem.
Author: Manlio Perillo (manlioperillo)
Date: 2004-06-18 16:42
Logged In: YES user_id=1054957
I have found a very simple patch.
First I have implemented this function:
import os
def isrealfile(file): """ Test if file is on the os filesystem """
if not hasattr(file, 'fileno'): return False
try: tmp = os.dup(file.fileno())
except: return False
else: os.close(tmp); return True
Microsoft implementation of stdout/err/in when no console is created (and when no pipes are used) actually are not 'real' files.
Then I have added the following code in sitecustomize.py:
import sys
class NullStream: """ A file like class that writes nothing """ def close(self): pass def flush(self): pass def write(self, str): pass def writelines(self, sequence): pass
if not isrealfile(sys.stdout): sys.stdout = NullStream()
if not isrealfile(sys.stderr): sys.stderr = NullStream()
I have tested the code only on Windows XP Pro.
P.S. isrealfile could be added in os module.
Regards Manlio Perillo
Author: Tim Peters (tim.peters) *
Date: 2004-06-20 03:13
Logged In: YES user_id=31435
Just noting that "the usual" way to determine whether you're running under pythonw is to see whether
sys.executable.endswith("pythonw.exe")
The usual way to get a do-nothing file object on Windows is to open the special (to Windows) file named "nul" (that's akin to opening the special file /dev/null on Unixish boxes).
Note that file('nul').fileno() does return a handle on Windows, despite that it's not a file in the filesystem.
Author: Manlio Perillo (manlioperillo)
Date: 2004-06-20 13:39
Logged In: YES user_id=1054957
Thanks for sys.executable and 'nul' hints!
I only want to add two notes:
- isrealfile(file('nul')) -> True
So 'nul' has a 'real' implementation
- sys.executables isn't very useful for me, since I can do: pythonw ascript.py > afile
In this case sys.stdout is a 'real file', so I don't want to redirect it to a null device.
In all cases, isrealfile work as I want.
Author: Bluebird (pfremy)
Date: 2004-12-23 15:19
Logged In: YES user_id=233844
Manlio, thanks a lot for the tip. I ran into the same problem (a program that can both be used with python.exe and pythonw.exe). I will apply your fix.
I think that the fix should be applied somehow to pythonw.exe, so that it does something more understandable to the user.
Author: anatoly techtonik (techtonik)
Date: 2008-11-17 13:12
Duplicate of #706263
History
Date
User
Action
Args
2022-04-11 14:56:04
admin
set
github: 40405
2008-11-17 16:23:27
amaury.forgeotdarc
set
status: open -> closed
resolution: duplicate
superseder: print in pythonw raises silent exception when no console available
2008-11-17 13:32:06
giampaolo.rodola
set
nosy: + giampaolo.rodola
2008-11-17 13:12:27
techtonik
set
nosy: + techtonik
messages: +
2004-06-15 20:34:40
manlioperillo
create