apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Proposal: new filepath API for search paths
Date Wed, 05 Feb 2003 20:26:03 GMT
++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   <brane@xbc.nu>   http://www.xbc.nu/brane/



Mime
View raw message