This all looks good, but I wonder if also having a simple function along the lines of unix's realpath wouldn't be a useful addition as well. I'd envisage soemthing whereby you just pass a path and it returns the full path using the current directory as a starting point. I can see room for both as they do slightly different things.
Basically, if I have just a path relative to where I am now ... use apr_realpath I want a full path based on a location plus a relative path ... use apr_dir_merge In some ways I'm not sure we'd ever use apr_realpath in apache, but other projects may well find it useful. Comments. david ----- Original Message ----- From: "William A. Rowe, Jr." <[EMAIL PROTECTED]> To: "David Reid" <[EMAIL PROTECTED]>; "APR Development List" <dev@apr.apache.org> Sent: Sunday, March 04, 2001 6:09 AM Subject: Re: apr_realpath > Here's what I envision... > > #define APR_DM_TRUECASE 0x01 > #define APR_DM_NOTABOVEROOT 0x02 > #define APR_DM_NOTRELATIVE 0x04 > #define APR_DM_NOTABSOLUTE 0x08 > #define APR_DM_CANONICAL 0x10 > > apr_status_t apr_dir_merge(char *newpath, const char *rootpath, const char *addpath, > apr_int32_t flags, apr_pool_t *p) > > Where rootpath may be null, but only newpath elements are proper cased. Why? > Since getting the true case is a slow operation, and we can trust rootpath either > doesn't matter (true name only instead of true path) or was already truecased, we > are halfway to the finish line :-) Also, don't assume root path is absolute. It > could simply be 'foo' and addpath could be 'bar', resulting in foo/bar. Or in that > same example, addpath could be '../../bar', resulting in '../bar' (relative to foo). > > NOTABOVEROOT means addpath can't be '../bar' [technically, it could. Should we allow > the case where root /foo/bar + '../bar' is not above root?] Note that NOTABOVEROOT > precludes returning a relative name that is '../anything', since that is above whatever > root path it would be concatinated to, later. > > NOTABSOLUTE and NOTRELATIVE mean just what they suggest. Note that if the product > is not absolute, the name is never truecased. > > Dirmerge will resolve all '..', '.', '//' and other pathing issues into a canonical > form, iff CANONICAL is flagged. If not, a slash will be added iff the rootpath isn't > slash terminated, e.g. 'foo' 'bar' will become 'foo/bar', but 'test/' 'path' won't > ever inherit an extra slash, ever if CANONICAL is not specified. > > Note especially, the rootpath is presumed to have been processed through the > appropriate TRUECASE and CANONICAL filters, and _only_ the addpath is parsed > by those rules. We are essensially asking, take this root, fix up this addpath, > and give us the new (more) complete path. > > Doing all of these operations as single-pass should be quite quick. Can we all > live with this API? Other ideas, suggestions or pointers to my ommissions? > > Sorry I couldn't wrap this today (and would like to read the feedback to this > proposal.) It's as fast as I can picture, and should work for 98% of the needs. > Comments are welcome. > > Bill > > > > > ----- Original Message ----- > From: "David Reid" <[EMAIL PROTECTED]> > To: "APR Development List" <dev@apr.apache.org> > Sent: Saturday, March 03, 2001 9:55 AM > Subject: apr_realpath > > > > Did we ever get a point of agreeing if we wanted to add apr_realpath? I > > seem to have deleted the emails concerning it but ISTR that there was a > > patch? > > > > david > > > > >
