apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: apr_proc_create() cmdtype flavors and environment inheritance; incompatible API change desired?
Date Fri, 11 Jun 2004 17:09:24 GMT
Joe Orton wrote:
> On Fri, Jun 11, 2004 at 11:42:19AM -0400, Jeff Trawick wrote:
> 
>>whether or not the envionment is inherited should be orthogonal to some 
>>other details of starting the program (via shell, searching or not 
>>searching PATH), but API does not reflect that
>>
>>I need a way to start the new process via the shell *and* inherit the 
>>environment of the calling process, but there is no such support at present.
>>
>>attached patch simplify_patch changes how the app tells APR whether or not 
>>environment should be inherited in general, reducing the number of cmdtype 
>>enums and at the same time increasing the number of ways apr_proc_create 
>>can be used; this seems appropriate for 1.0
> 
> 
> Sounds good in theory, but do all these combos have direct maps to an
> exec* though? I don't see an exec* which takes an env pointer and
> searches $PATH for the program, for instance...

the two new combinations allowed by the API would be

search PATH but don't inherit environment
-> no direct exec*() implementation but no rocket science required to implement

start via shell and do inherit environment
-> attached patch shows how

Beyond unix there is the question of netware and win32 and os/2 and whatever else.

I'm guessing from current netware code that the environment is never explicitly 
inherited (though perhaps its decision on when to run in current address space 
takes care of that).

AFICT OS/2 already handles environment independently of cmdtype, as if env 
parameter meaning null means to inherit environment and non-env parameter means 
to use that environment.

Win32 seems to have that capability as well.

BeOS has the tell-tale comment

   /* ### we should be looking at attr->cmdtype in here... */

and always passes the env parameter to the system call.

>>attached patch extend_patch adds yet another cmdtype flavor so app can 
>>specify to run the command via the shell and have it inherit the 
>>environment of the calling process; this seems appropriate for 0.9
> 
> 
> Actually, doesn't that happen by default already on Unix?  It's passing
> the env pointer through to execve, right?

execve() means that the environment isn't inherited; the caller would have to 
pass the current environment to APR in the env parameter to apr_proc_create() 
in order for that to work

Attached is the further change to threadproc/unix/proc.c to take the implement 
APR_SHELLCMD_ENV and call execv() or execve() as appropriate:


Mime
View raw message