You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Sterling Hughes <st...@designmultimedia.com> on 2001/08/01 13:00:40 UTC

[patch] apr_pathinfo()

    Hi,

    I've recently needed functionality to portably analyze the different
    parts of an OS path (ie, /home/foo.com/www/test.xml), therefore,
    I've written the following function, loosely based on
    apr_filename_from_pathname() which returns the information on a OS path
    into a structure (the name of the file, the directory path, and the
    file ending).

    Attached is a patch which removes the apr_filename_from_pathname()
    function, and adds the apr_pathinfo() function.  I've split the
    apr_pathinfo() function into a seperate file (apr_path.c) simply
    because apr_cpystrn.c (where apr_filename_from_pathname() was
    implemented) just didn't seem to be the proper place to put the
    function.  Actually, not to start another thread, but.. there
    doesn't really seem to be a standard file to put some assorted
    string functions in (like apr_strlib.c or something).

    Another note is that these functions take a pool to allocate memory,
    historically these type of functions don't behave like this (dirname()
    and basename() for example).  But, I've found (personally) that it
    leads to some annoying errors, therefore each portion of the string
    that is extracted is duplicated.  I don't anticipate this being a
    huge deal, mainly because at most you're copying a couple of characters
    (*duck*).

    -Sterling

    Ps: The path splitting functionality is not at all equivalent to
    dirname() or basename(), I think it makes sense this way, however,
    if people really want, I can make it dirname() and basename()
    compliant.

    Pps: Again sorry the patch is a bit big ;)

Re: [patch] apr_pathinfo()

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
I'd be happy to take a look at this, thank you.  The implementation as it were
is already in need of some refactoring for 'real life' uses, and Apache's own
directory_walk and a few remaining ap_foo functions needed to be depricated.
This should help.

----- Original Message ----- 
From: "Sterling Hughes" <st...@designmultimedia.com>
To: <de...@apr.apache.org>
Sent: Wednesday, August 01, 2001 6:00 AM
Subject: [patch] apr_pathinfo()


>     Hi,
> 
>     I've recently needed functionality to portably analyze the different
>     parts of an OS path (ie, /home/foo.com/www/test.xml), therefore,
>     I've written the following function, loosely based on
>     apr_filename_from_pathname() which returns the information on a OS path
>     into a structure (the name of the file, the directory path, and the
>     file ending).
> 
>     Attached is a patch which removes the apr_filename_from_pathname()
>     function, and adds the apr_pathinfo() function.  I've split the
>     apr_pathinfo() function into a seperate file (apr_path.c) simply
>     because apr_cpystrn.c (where apr_filename_from_pathname() was
>     implemented) just didn't seem to be the proper place to put the
>     function.  Actually, not to start another thread, but.. there
>     doesn't really seem to be a standard file to put some assorted
>     string functions in (like apr_strlib.c or something).
> 
>     Another note is that these functions take a pool to allocate memory,
>     historically these type of functions don't behave like this (dirname()
>     and basename() for example).  But, I've found (personally) that it
>     leads to some annoying errors, therefore each portion of the string
>     that is extracted is duplicated.  I don't anticipate this being a
>     huge deal, mainly because at most you're copying a couple of characters
>     (*duck*).
> 
>     -Sterling
> 
>     Ps: The path splitting functionality is not at all equivalent to
>     dirname() or basename(), I think it makes sense this way, however,
>     if people really want, I can make it dirname() and basename()
>     compliant.
> 
>     Pps: Again sorry the patch is a bit big ;)
>