Re: [AD] Relative paths in the grabber

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> Ok, revised patch attached.

Thanks.

> I haven't done any unicode optimizations, but I've fixed the capitalization
> in the menu and the missing shortcuts. I also got rid of the
> fix_filename_forwardslashes() hack, which indeed doesn't seem to be
> necessary.

I'll do the Unicode optimizations when merging the patch.

> The find_relative_path() function still uses '/' as a path seperator when
> constructing the relative path, but it will call fix_filename_slashes()
> before returning, thus returning the path in the proper format for the
> current platform.
> It now fails for deliberately hacked paths that mix \ and /, but that
> probably isn't a problem.

I'm now contemplating making it part of the API because:
- it is non-trivial to implement, particularly in a platform-independent way,
- it has the opposite functionality of replace_filename()+fix_filename_path()
- I'd like the dat utility to support the relative paths functionality too 
(luckily enough, one of the few unused letters for an option is 'r').


I'm actually thinking about adding two new API functions:

char *calculate_absolute_filename(char *dest, const char *path, const char 
*filename, int size);

char *calculate_relative_filename(char *dest, const char *path, const char 
*filename, int size);

The first one would be basically replace_filename()+fix_filename_path() and 
the second one would be your code.


I'm also thinking about renaming fix_filename_path() whose name is IMHO 
misleading because:
- it doesn't "fix" the filename like the other two fix_filename_*() functions 
which really modify the filename and don't need a 'dest' parameter,
- the name is too vague,
so I'd propose canonicalize_filename() instead (which happens to be the 
description of the function in src/file.c :-) and to deprecate 
fix_filename_path().

-- 
Eric Botcazou