Eric Blake <[EMAIL PROTECTED]> writes:
> Should I add a dependency on the verify module to ensure that drive
> letter prefixes are only used on ASCII platforms?
I wouldn't bother, unless there's a serious possibility that we'll see
drive letter prefixes on an EBCDIC platform. I think that unlikely.
Besides, if we ever port to OS/360, we'll need to rewrite all this
code anyway -- their file name syntax is _weird_.
> Should I still move FILE_SYSTEM_PREFIX_LEN out of config.h and into
> dirname.h?
I'd rather move it out of config.h, yes. I have some qualms with
config.h containing ifdefs.
> POSIX poses the rule as: if "$string" is a valid filename, then 'cd
> "$(dirname "$string")"; ls "$(basename "$string")"' lists the same
> file
Yes, that's a better way to formulate the constraint (though it's not
a complete spec).
> (although POSIX fails to mention that this will fail if the
> filename contains a trailing newline).
That problem doesn't occur for dir_name and base_name though, right?
At least on Unix-like platforms.
> My patch makes base_name("c:/") return "".
Is "" a valid file name? If not, then we're violating the constraint.
I don't know the DOS rules, but I suspect that the only suffix of
"c:/" that identifies the same file is "c:/" itself; in that case,
base_name("c:/") should return "c:/".
> For that matter, would it help to redefine our base_name to ALWAYS return
> the empty string if the argument is a root directory?
That might be simpler, yes, but due to backward-compatibility concerns
I might be inclined to give that function a different name --
base_component perhaps.
> Another thing to think about. Currently, strip_trailing_slashes("///")
> currently calls base_name("///"), gets a single "/", skips past that
> slash, then returns false (leaving the user with "///" still). But it
> might be more intuitive if it changed the input string to "/\0/" and
> returned true.
Yes, that's true.
I'd like someone to review the uses of base_name, dir_name, etc. in
coreutils and tar. This will give us a better feeling for how these
changes would affect real code. Perhaps our backward-compatibility
concerns are unwarranted....
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
