You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Branko Čibej <br...@xbc.nu> on 2003/02/05 20:58:48 UTC
Proposal: new filepath API for search paths
I'd like to propose a new function in the apr_filepath module, to be
added for 0.9.2 and/or httpd-2.0.45:
/**
* Split a search path defined in an environment variable (e.g., @c $PATH)
* into separate components
* @ingroup apr_filepath
* @param pathelts the returned components of the search path
* @param envvar the name of the environment variable with the search path
* @param p the pool to allocate the array and path components from
* @deffunc apr_status_t apr_filepath_splitenv(apr_array_header_t **pathelts, const char *envvar, apr_pool_t *p)
* @remark if the environment variable does not exist, the result code will
* be @c APR_ENOENT; other codes are implementation-specific.
*/
APR_DECLARE(apr_status_t) apr_filepath_splitenv(apr_array_header_t **pathelts,
const char *envvar,
apr_pool_t *p);
The apr-iconv module would use this to interpret the APR_ICONV_PATH
variable in a way that's compatible with other functions that accept
paths (e.g., the returned path components would be in UTF-8 on most
Windows variants). For example, the module loading code in
iconv-module.c would look like the following, instead of the apr_strtok
based implementation we have now:
status = apr_filepath_splitenv(&pathelts, "APR_ICONV_PATH", subpool);
if (!status)
{
int i;
char **elts = (char **)pathelts->elts;
for (i = 0; i < pathelts->nelts; ++i)
{
if (iconv_getpathname(buf, elts[i], buffer, subpool) == 0)
{
apr_pool_destroy(subpool);
return APR_SUCCESS;
}
}
}
I have a workinng Windows and Unix implementation, but would like to get
some feedback on the proposed interface before checking in the code.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: Proposal: new filepath API for search paths
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:22 PM 2/5/2003, Branko Äibej wrote:
>This is where it stops working. On Windows, at least on NT-class
>systems, you really do want to use the wide char functions to read the
>environment and convert the result to UTF-8, otherwise we're not safe in
>the presence of characters that can't be represented in the current
>locale. I don't want to lose that capability, after all the trouble we
>(you?) went to in the other I/O functions.
Look at what we are doing in apr_app_initialize ... actually yes - the
environment is utf8'ed from the 'pure' Unicode command line and
environment table.
However ... if you are using it as a library that doesn't build for APR,
you are right, we can't really do this. I don't have any objection to
an apr_env_get/_set() api (especially since setenv doesn't exactly
do what users expect on win32.)
Let's tackle the one, then the apr_env api :-)
Bill
Re: Proposal: new filepath API for search paths
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
>William A. Rowe, Jr. wrote:
>
>
>>Let's drop the 'env' concept - this is really useful overall.
>>
>>And please be careful to strip quotes from around elements, and add
>>quotes (or on unix, backslash escape) the seperator element (e.g. colon
>>or semicolon.)
>>
>>
>>
>Sure. I think we already have code that can do that, so I might want to
>do a bit of refactoring.
>
>
It strikes me that we do _not_ want to fiddle with quotes and excaping
here. Neither Unix nor Windows paths need quotes or backslash escapes.
As for APR functions, apr_file_open and friends don't need them; only
apr_proc_create does (because the shell might be involved), and the
Win32 version _adds_ quotes around the program mane if it contains
spaces. The Unix version doesn't do that, but I suspect that's a bug in
apr_proc_create.
I've never seen any quotes in PATH on Windows, nor any escapes on Unix,
nor can I find any docs mandating such. As for the ...list_merge
function, I think it's the caller's responsibility to pass in paths that
are suitalbe for apr_file_open.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: Proposal: new filepath API for search paths
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
>++1 if we can go with
>
>APR_DECLARE(apr_status_t) apr_filepath_list_split(
> apr_array_header_t **pathelts, const char *liststr, apr_pool_t *p);
>
>APR_DECLARE(apr_status_t) apr_filepath_list_merge(
> char **liststr, apr_array_header_t *pathelts, apr_pool_t *p);
>
I could definitely do that.
>Let's drop the 'env' concept - this is really useful overall.
>
>And please be careful to strip quotes from around elements, and add
>quotes (or on unix, backslash escape) the seperator element (e.g. colon
>or semicolon.)
>
Sure. I think we already have code that can do that, so I might want to
do a bit of refactoring.
>Sure the default docs can illustrate the typical
>
> apr_filepath_list_split(patharr, getenv("PATH"), p);
>
>but I think we want to stay away from overloading both getenv and split
>list facilities into a single function. It makes the API less useful :-)
>
This is where it stops working. On Windows, at least on NT-class
systems, you really do want to use the wide char functions to read the
environment and convert the result to UTF-8, otherwise we're not safe in
the presence of characters that can't be represented in the current
locale. I don't want to lose that capability, after all the trouble we
(you?) went to in the other I/O functions.
apr_filepath_getenv, maybe? (Put it in the apr_filepath namespace
because the value it returns is suitable for input into other apr_file*
functions.)
>Oh, you might plan for a flags element for options like APR_FILEPATH_NATIVE
>where we could even do colon, forward slashed paths by default and follow
>the platform convention when APR_FILEPATH_NATIVE is passed ;-)
>
Bah. We have apr_filepath_merge; there's no need to duplicate that
functionality, is there?
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: Proposal: new filepath API for search paths
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
++1 if we can go with
APR_DECLARE(apr_status_t) apr_filepath_list_split(
apr_array_header_t **pathelts, const char *liststr, apr_pool_t *p);
APR_DECLARE(apr_status_t) apr_filepath_list_merge(
char **liststr, apr_array_header_t *pathelts, apr_pool_t *p);
Let's drop the 'env' concept - this is really useful overall.
And please be careful to strip quotes from around elements, and add
quotes (or on unix, backslash escape) the seperator element (e.g. colon
or semicolon.)
Sure the default docs can illustrate the typical
apr_filepath_list_split(patharr, getenv("PATH"), p);
but I think we want to stay away from overloading both getenv and split
list facilities into a single function. It makes the API less useful :-)
Oh, you might plan for a flags element for options like APR_FILEPATH_NATIVE
where we could even do colon, forward slashed paths by default and follow
the platform convention when APR_FILEPATH_NATIVE is passed ;-)
Bill
At 01:58 PM 2/5/2003, Branko Äibej wrote:
>I'd like to propose a new function in the apr_filepath module, to be
>added for 0.9.2 and/or httpd-2.0.45:
>
>/**
> * Split a search path defined in an environment variable (e.g., @c $PATH)
> * into separate components
> * @ingroup apr_filepath
> * @param pathelts the returned components of the search path
> * @param envvar the name of the environment variable with the search path
> * @param p the pool to allocate the array and path components from
> * @deffunc apr_status_t apr_filepath_splitenv(apr_array_header_t **pathelts, const char *envvar, apr_pool_t *p)
> * @remark if the environment variable does not exist, the result code will
> * be @c APR_ENOENT; other codes are implementation-specific.
> */
>APR_DECLARE(apr_status_t) apr_filepath_splitenv(apr_array_header_t **pathelts,
> const char *envvar,
> apr_pool_t *p);
>
>
>The apr-iconv module would use this to interpret the APR_ICONV_PATH
>variable in a way that's compatible with other functions that accept
>paths (e.g., the returned path components would be in UTF-8 on most
>Windows variants). For example, the module loading code in
>iconv-module.c would look like the following, instead of the apr_strtok
>based implementation we have now:
>
> status = apr_filepath_splitenv(&pathelts, "APR_ICONV_PATH", subpool);
> if (!status)
> {
> int i;
> char **elts = (char **)pathelts->elts;
> for (i = 0; i < pathelts->nelts; ++i)
> {
> if (iconv_getpathname(buf, elts[i], buffer, subpool) == 0)
> {
> apr_pool_destroy(subpool);
> return APR_SUCCESS;
> }
> }
> }
>
>
>I have a workinng Windows and Unix implementation, but would like to get
>some feedback on the proposed interface before checking in the code.
>
>--
>Brane Äibej <br...@xbc.nu> http://www.xbc.nu/brane/