Martin v. Löwis wrote:
Exactly. My proposal is still to provide an API to toggle the
flag after the handle was created.
OK, here is an API that I tested on Windows and for sockets only.
Perhaps someone can test it on Non-Windows (Linux, for example?)
I think the best place for it would be as
I think the best place for it would be as a new method set_noinherit
for file and socket objects or as a new function in the os module
(thus the implementation should probably be rewritten at the C level).
Indeed. Can you come up with a C implementation of it?
I think it should be a function
# I'm not sure about netiquette here:
# I decided to continue posting to the python-list without CCing to
everyone.
[I assume you mean python-dev]
Discussing this issue on the list is fine. Posting code is on the
borderline, and will have no effect, i.e. no action will come out
of (at least
My very personal opinion:
After a sleepness night, it seems to me that this is not a Python problem
(or any other programming language at all).
It looks more like an OS design problem (on MS Windows as well as
on Linux etc). In an ideal world, when a program asks the OS to start
a child process,
Putting it into the library is fine. However, we need to find
an implementation strategy that meets the user's needs, and
is still maintainable.
Python 3 will offer a clean solution, deviating entirely from
stdio.
Let me point out that stdio is not the problem.
The problem is handle
On Jun 24, 2007, at 2:19 PM, Martin v. Löwis wrote:
I don't see why it is a requirement to *open* the file in
non-inheritable mode. Why is not sufficient to *modify*
an open file to have its handle non-inheritable in
an easy and platform-independent way?
Threads. Consider that you may fork a
I don't see why it is a requirement to *open* the file in
non-inheritable mode. Why is not sufficient to *modify*
an open file to have its handle non-inheritable in
an easy and platform-independent way?
Threads. Consider that you may fork a process on one thread right
between the calls to
On Sun, Jun 24, 2007 at 10:48:30PM +0200, Martin v. Löwis wrote:
I don't see why it is a requirement to *open* the file in
non-inheritable mode. Why is not sufficient to *modify*
an open file to have its handle non-inheritable in
an easy and platform-independent way?
Threads. Consider
Henning von Bargen schrieb:
I'd like to propose a new function open_noinherit
or maybe even a new mode flag n for the builtin open
(see footnote for the names).
Do you have a patch implementing that feature? I believe
it's unimplementable in Python 2.x: open() is mapped
to fopen(), which does
OT: Argh - my email address is visible in the posting - I am doomed!
- Original Message -
Martin v. Löwis wrote:
Do you have a patch implementing that feature? I believe
it's unimplementable in Python 2.x: open() is mapped
to fopen(), which does not support O_NOINHERIT.
Yes, I
Yes, I have a patch implemented in pure Python.
I got the code on my workplace PC (now I am writing from home,
that's why I said I'll post the code later).
The patch uses os.fdopen ( os.open (..., ...), ...).
It translates IOError into OSError then to raise the same class
of exception
Martin v. Löwis wrote:
Yes, I have a patch implemented in pure Python.
I got the code on my workplace PC (now I am writing from home,
that's why I said I'll post the code later).
The patch uses os.fdopen ( os.open (..., ...), ...).
It translates IOError into OSError then to raise the
The kind of errors I mentioned (permission denied errors that
seem to occur without an obvious reason) have cost me at least
two weeks of debugging the hard way (with ProcessExplorer etc)
and caused my manager to loose his trust in Python at all...
I think it is well worth the effort to keep
As you can see, at the C level, basically fopen is open with a
little code around it to parse flags etc. It's the same kind of hackish code.
little code is quite an understatement. In Microsoft's C library
(which we would have to emulate), the argument parsing of fopen is
120 lines of code. In
On Sat, Jun 23, 2007 at 08:39:38AM -0700, Stephen Hansen wrote:
I just wanted to express to the group at large that these experiences aren't
just Henning's; we spent a *tremendous* amount of time and effort debugging
serious problems that arose from file handles getting shared to subprocesses
Stephen,
thank you for speaking it out loud on python-dev.
And you know better english words like tremendous
and obtuse (whatever that means:-)
that express what a PITA this really is.
When I said it took me two weeks, that's actually not the truth.
It was even more.
The first problem was with
One fix is to always use subprocess.Popen and specify that
close_fd=True, which wasn't difficult for me, but I can imagine that
an easy way to set close-on-exec would be simpler in other cases.
I think the complaint is not so much about simplicity, but correctness.
close_fd also closes
Hi,
I think the complaint is not so much about simplicity, but correctness.
close_fd also closes stdin/stdout/stderr, which might be undesirable
and differs from POSIX.
According to the docs, stdin/stdout and stderr are not closed (
http://docs.python.org/lib/node529.html)
Matthieu
I think the complaint is not so much about simplicity, but correctness.
close_fd also closes stdin/stdout/stderr, which might be undesirable
and differs from POSIX.
According to the docs, stdin/stdout and stderr are not closed (
http://docs.python.org/lib/node529.html)
I
I'd like to propose a new function open_noinherit
or maybe even a new mode flag n for the builtin open
(see footnote for the names).
The new function should work exactly like the builtin open, with one
difference:
The open file is not inherited to any child processes
(whereas files opened with
20 matches
Mail list logo
