Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Bug in Filename.basename?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-09-05 (20:54)
From: Oliver Bandel <oliver@f...>
Subject: Re: [Caml-list] Bug in Filename.basename?
Zitat von Mattias EngdegÄ   rd <>:

> >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).