[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Path searching in svn_io_start_cmd

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-11-19 01:50:29 CET

kfogel@collab.net wrote:
> Julian Foad <julianfoad@btopenworld.com> writes:
>> From svn_io_start_cmd():
>>> * @a inherit sets whether the invoked program shall inherit its environment or
>>> * run "clean".
>>>/* Make sure we invoke cmd directly, not through a shell. */
>>>apr_err = apr_procattr_cmdtype_set (cmdproc_attr,
>>That should be "APR_PROGRAM_ENV", not "APR_PROGRAM_PATH", else
>>path-search is enabled as well as env. But didn't we specifically
>>want path-search for our external "diff" support? Is that diff
>>support relying on an undocumented feature (path search)?
>>Something's wrong. Anyone care to decide what?
> Are they bitmasks, and if so, shouldn't we do both? That is:
> apr_err = apr_procattr_cmdtype_set
> (cmdproc_attr,

Er... no. They're not bit masks. APR_PROGRAM_PATH already means "env + path".
  APR_PROGRAM, on the other hand, means "no env, no path".

The bug is that in our present implementation the "inherit" argument controls
both inheriting the environment and searching the path, where the latter should
presumably be an independent, orthogonal feature if it is wanted at all.

There doesn't seem to be a "path but not env" variant available directly from
APR. From apr/include/apr_thread_proc.h:

typedef enum {
     APR_SHELLCMD, /**< use the shell to invoke the program */
     APR_PROGRAM, /**< invoke the program directly, no copied env */
     APR_PROGRAM_ENV, /**< invoke the program, replicating our
environment */
     APR_PROGRAM_PATH, /**< find program on PATH, use our environment */
     APR_SHELLCMD_ENV /**< use the shell to invoke the program,
                              * replicating our environment
} apr_cmdtype_e;

I submit that there should be a "path but no env" variant in APR. The fact
that it may be difficult to implement is no excuse :-)

Given that there isn't, do we want to simulate it in Subversion, or avoid the
problem, just updating our doc to describe what we have implemented, or what?

> (I'm not sure if the feature is "undocumented" so much as "assumed" :-) ).

Er... what?

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 19 01:51:06 2005

This is an archived mail posted to the Subversion Dev mailing list.