On Wed, Mar 14, 2001 at 09:38:21AM -0600, William A. Rowe, Jr. wrote:
> From: "Kevin Pilch-Bisson" <[EMAIL PROTECTED]>
> Sent: Wednesday, March 14, 2001 7:48 AM
>
> >> Attachment
>
> Huge favor, if you would, look into why all your posts are going in as text
> file
> attachments? At least they appear so on my pathetic Win32 email client.
Sorry, I think it has to do with the way mutt handles pgp signing
messages. I'm not going to sign this one, so hopefully it won't do so.
Offhand, which pathetic win32 client.
>
> To answer your questions:
>
> apr_filepath_merge(char **newpath, char *rootpath, char **addedpath,
> APR_FILEPATH_TRUEPATH, p)
>
> would allow us to take rootpath of '/usr/local/bin' and addedpath of
> 'apache/secure/conf',
> merge them into '/usr/local/bin/apache/' [an existing path] and leave
> addedpath pointing
> to 'secure/conf' [the non-existant portion of addedpath.] The user can do
> whatever they like
> to make them work.
[snip explanation]
OOhhh, now I understand. I like!
>
> My only other 'simple' solution, if that flag is passed, is to append a
> second string following
> the null of the root string. If they pass that flag, the user is guarenteed
> a second null
> (even if the entire given path was existed, so the non-existant result is
> empty.)
>
> Since that is alien to everything we have done in APR, I'm hesistant to try
> it.
No, no, no. I don't like that at all.
>
>
> I didn't miss your question on comparing paths, we need to add these other
> functions:
Actually, for now I think I can do what I need with just
apr_filepath_merge, with NULL, rootpath arguments. (We have existing
svn functions to do the rest, although in time they would probably be
re-worked to use the below).
>
> apr_status_t apr_filepath_root(char** pathroot, char** name, apr_pool_t *p)
> Which returns the canonical form of the pathroot and returns the first
> non-root
> part of name (e.g. '/foo' is '/' 'foo' on unix, 'c:\foo' is 'c:\' 'foo'
> and
> '//machine/share/foo' is '//machine/share/' 'foo' on win32)
> Handles incomplete roots ('c:foo' on win32 is 'c:', 'foo', but returns a
> status
> of APR_EINCOMPLETE).
Would there be a way to convert an incomplete path to a complete path?
(change drive to c:, getpwd, append foo, in the above example)
>
> apr_status_t apr_filepath_elements_count(int *n, char *path)
> counts the elements given in the file path.
> [counts the root as one element]
>
> apr_status_t apr_filepath_elements_get(char **segments, char *path, int
> first, int last, apr_pool_t *p)
> returns the requested elements of the file path.
> All even numbered elements are delimiters, so 0 is the delimited root,
> 1 is the first name, 2 is the delimiter, 3 is the second name.
> While more complex, this presupposes some platform could have a multi-byte
> delimiter (unlikely, but consider a utf-8 path delimiter char that is more
> than a single byte, not true of '/' or '\', but it's easier to code for it
> now than change it later.)
>
> The even/odd theory falls apart for relative paths like foo/bar unless we
> return an
> empty string for foo, so this needs more thought.
Will keep thinking about this.
>
> apr_status_t apr_filepath_common(char** result, char* a, char* b, apr_pool_t
> *p)
> returns the segments that match, comparing from the beginning.
> The user must canonicalize the paths first with apr_filepath_merge.
> /foo/bar compared to /foo/barstool returns /foo/
> compare does not distinguish between '/' and '\' on win32/os2 - they
> compare equal.
> If a and b were char**, we could point at the first uncommon element, but
> a strlen
> of result provides the same answer, no? [This isn't true of the above
> example that
> is changing the case, eliminating trailing '.'s and ' 's from win32
> names, and
> converting short aliases to true names).
>
> Canonicalizing first to the truename is required before apr_filepath_common
> can be
> trusted on Win32 or OS2, since c:/thislongname/ is also c:/THISLO~1/
Canonicalizing is done by apr_filepath_merge, with NULL rootpath, right?
>
> Bill
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
