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" <[EMAIL PROTECTED]> To: <[email protected]> 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 ;) >
