Re: [Caml-list] Bug in Filename.basename?

[Oliver Bandel <oliver@first.in-berlin.de>]

Zitat von Mattias Engdegå   rd <mattias@virtutech.se>:

> >Looking at that documentation, I can't see no bug in the implementation.
>
> As an extra data point, Python's os.path.basename("a/b/c/") returns "".
> It is defined to return "the final component of a pathname".
[...]

Using a perspective of view, based on string-handling, this might
be a good way (to use "").

But an empty string makes no sense, when it is interpreted as
part of a path. But "." makes sense in a path, and it refers to the
current directory. In the context of Filename,dirname and Filename.basename
this means, that if you give a directory-name, you have the basename
also indicating that it is a directory: the directory, which's
name can be find out by Filename.dirname.

==================================================
# let f n = (Filename.dirname n , Filename.basename n);;
val f : string -> string * string = <fun>
# f "/usr/lib";;
- : string * string = ("/usr", "lib")
# f "/usr/lib/";;
- : string * string = ("/usr/lib", ".")
# f "usr/lib";;
- : string * string = ("usr", "lib")
# f "usr/lib/";;
- : string * string = ("usr/lib", ".")
#
==================================================

So, the "." always make sense, but the empty string does not.
The file "." is not a regular file, it is the current dir,
which also is a file, but of different type than regular files or sockets...


>
> Python's basename/dirname pair have the same concatenative properties
> as O'Caml's so this makes sense in both languages.

OK, but the contents of "" can't be shown.
It's not a regular file and not a directory.

"." means a file of type directory (the current one), and that makes sense.
So "/usr/." makes sense.


>
> This is probably also more useful than the semantics of basename(1).
>


Yes.

Ciao,
   Oliver