This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients filip.zyzniewski, neologix
Date 2012-12-07.14:57:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM38a5pCQqxKNgbRURdNvCEW5gQ88N6gQOLGy15pTykRMQ@mail.gmail.com>
In-reply-to <1354889283.34.0.359637854781.issue16635@psf.upfronthosting.co.za>
Content
> If stdout was closed before closing stderr, then stdout problems
> could be reported, and that is what I would expect when using Python
> this way.

To be consistent, we should also close stderr, and then we couldn't
report any subsequent error.

> os.fsync(1) helps, but only if preceeded by sys.stdout.flush() and it
> seems a bit cumbersome.

You should complain to the POSIX committee ;-)
The thing is simply that if you want to make sure that data is
committed (or get an error otherwise), you should call fsync() on the
file descriptor. Just having close return 0 doesn't guarantee that
data is committed, in the general case (NFS is a special case with its
close-to-open cache consistency).

> cat, grep, dd and echo close their stdout, why couldn't Python do this?

bash, dmesg, ifconfig and many others don't.

It could probably be possible, but I don't think the benefit is worth
the trouble.
History
Date User Action Args
2012-12-07 14:57:56neologixsetrecipients: + neologix, filip.zyzniewski
2012-12-07 14:57:56neologixlinkissue16635 messages
2012-12-07 14:57:56neologixcreate