Eric Blake <[EMAIL PROTECTED]> writes:
> OK, how about this approach: continue with the current rule that base_name
> always returns a pointer into the original string without modification.
> On systems where drive prefixes exist, have base_name("a:") return "" (it
> is a root), but base_name("foo/a:b") return "a:b". Then provide a second
> function, abase_name, which malloc()s the memory for storing the last
> component. Normally it will just strdup() the base_name of the original
> string, but it does the right thing where base_name is empty (a root, so
> abase_name("a:") gives "a:" instead of "") or where base_name results in a
> drive letter (a multi-component path, so abase_name("foo/a:b") results in
> "./a:b").
I'm trying to map this to the bigger picture, and coming up empty.
Among other things, I don't like having "" be a special case.
How about the following idea instead? Let's omit abase_name and just
have base_name. Then we use this rule:
If you have a valid file name F, then accessing F is the same as
chdir(dir_name(F)) followed by accessing base_name(F). Furthermore
if you successfully { chdir(dir_name(F)); rename(base_name(F),"foo"); },
you have renamed F to a file named "foo" in the same directory that F was in.
If we go this route, then base_name(F) cannot in general yield a
suffix of F even on Unix systems, since we would want dir_name("a/b/")
== "a/b" and base_name("a/b/") == ".". Hence base_name will need to
allocate memory in general, even on Unix. On Cygwin it will need it
to compute "./a:b".
Also, src/dirname.c and src/basename.c will have to be modified to
strip redundant trailing slashes before invoking dir_name and
base_name.
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
