Re: bugs in dirname module

[Paul Eggert]

Eric Blake <address@hidden> 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....