Boost logo

Boost :

Subject: Re: [boost] Boost.Process article: Tutorial and request for comments
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2009-04-25 10:13:16


Boris Schaeling wrote:
> On Tue, 21 Apr 2009 20:15:11 +0200, Phil Endecott wrote:

>> Re the environment: I'm not enthusiastic that you have copied the
>> environment into your own data structure. Why can't your environment
>> type just wrap getenv() and setenv()? i.e.

> The type environment is also used to setup a new environment for a child
> process, eg.:
>
> context ctx;
> ctx.environment.insert(environment::value_type("PATH", "/newpath"));
> launch(..., ctx);

Typically I would write:

fork();
setenv("PATH","/newpath");
exec();

So the new child process gets the parent's environment with any new
variables added or changed. This seems a lot simpler than copying the
whole environment.

>> Why don't you boil it down to:
>>
>> launch_process("notepad.exe");
>
> Currently the environment variables of the current process are not
> automatically inherited by a child process. I agree that it should be
> easier to launch a new process. But then environment variables should
> probably be inherited by default?

The environment is inherited across fork() and all those versions of
exec() that don't explicitly set a new environment.

>>> it is very important to refer to the executable with an absolute path -
>>> on all platforms including POSIX systems
>>
>> Why do you say that?
>
> It's a requirement of Boost.Process. It doesn't need to be an absolute
> path but can also be a relative path of course.

Right, so it doesn't need to be an absolute path.

> What's not guaranteed
> though is that an executable is automatically found when only a filename
> is given. There is a function which searches for an executable and returns
> an absolute path. Would you like to see Boost.Process search for an
> executable automatically?

No, I'd like to see it use one of the versions of exec() that does this
for you.

Regards, Phil.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk