Re: apr_proc_create() cmdtype flavors and environment inheritance; incompatible API change desired?

[Jeff Trawick]

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:

Index: threadproc/unix/proc.c
===================================================================
RCS file: /home/cvs/apr/threadproc/unix/proc.c,v
retrieving revision 1.72
diff -u -r1.72 proc.c
--- threadproc/unix/proc.c      13 Feb 2004 09:38:37 -0000      1.72
+++ threadproc/unix/proc.c      11 Jun 2004 16:37:56 -0000
@@ -385,7 +385,8 @@
             exit(-1);   /* We have big problems, the child should exit. */
         }
 
-        if (attr->cmdtype == APR_SHELLCMD) {
+        if (attr->cmdtype == APR_SHELLCMD ||
+            attr->cmdtype == APR_SHELLCMD_ENV) {
             int onearg_len = 0;
             const char *newargs[4];
 
@@ -436,7 +437,12 @@
                 apr_proc_detach(APR_PROC_DETACH_DAEMONIZE);
             }
 
-            execve(SHELL_PATH, (char * const *) newargs, (char * const *)env);
+            if (attr->cmdtype == APR_SHELLCMD) {
+                execve(SHELL_PATH, (char * const *) newargs, (char * const 
*)env);
+            }
+            else {
+                execv(progname, (char * const *)args);
+            }
         }
         else if (attr->cmdtype == APR_PROGRAM) {
             if (attr->detached) {