In article <[EMAIL PROTECTED]>,
Yves Glodt <[EMAIL PROTECTED]> wrote:
> David Wahler wrote:
> > Yves Glodt wrote:
> >> It does, I did like this:
> >>
> >> os.umask(0113)
> >> newpid =
> >> os.spawnl(os.P_NOWAIT,'/usr/local/bin/wine','/usr/local/bin/wine',executabl
> >> e)
> >>
> >> But I wanted to use spawnle and it's env argument, to avoid setting
> >> umask manually...
> >
> > The umask is not part of the environment, so there's no way to set it
> > directly through spawnle.
>
> ok
>
> > Why don't you want to use os.umask?
>
> Only because I thought spawnle could set it through env...
> But as it can't I will now go with os.umask.
On UNIX, the "spawn" functions are just Python code that wraps up
the low level fork and execve system calls. There's no reason you
can't write your own version if you like, that does what you need.
It does make sense to want to modify umask and who knows what other
inheritable context in the fork, so you might be thinking of an
API with a function that's called at that time, like
spawnve(wait, file, args, env, func)
The funny thing is, that's such a good idea that the implementation
already has a function with that signature. The only difference is
that func() also must call the appropriate execve function. So for
example,
def execumask113(file, args, env):
os.umask(0113)
return os.execve(file, args, env)
...
os._spawnvef(os.P_NOWAIT, '/usr/local/bin/wine',
['wine', exe], os.environ, execumask113)
Now the problem is that this function is evidently not part of the
published API for os.py, so it would be unseemly to complain if it
were to change in later versions. So I guess the right thing to do
is write your own spawn function from the ground up. But at least
you have some ideas there about how it might work.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
