From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 3581FBC6B for ; Wed, 5 Sep 2007 22:54:20 +0200 (CEST) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l85KsJHE022495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Sep 2007 22:54:19 +0200 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from einhorn.in-berlin.de (localhost [127.0.0.1]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id l85KsJm6025181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 5 Sep 2007 22:54:19 +0200 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id l85KsJTN025179 for caml-list@inria.fr; Wed, 5 Sep 2007 22:54:19 +0200 X-Authentication-Warning: einhorn.in-berlin.de: www-data set sender to oliver@first.in-berlin.de using -f Received: from dslb-088-073-068-051.pools.arcor-ip.net (dslb-088-073-068-051.pools.arcor-ip.net [88.73.68.51]) by webmail.in-berlin.de (IMP) with HTTP for ; Wed, 5 Sep 2007 22:54:19 +0200 Message-ID: <1189025659.46df177b073a6@webmail.in-berlin.de> Date: Wed, 5 Sep 2007 22:54:19 +0200 From: Oliver Bandel To: caml-list@inria.fr Subject: Re: [Caml-list] Bug in Filename.basename? References: <20070905184538.88ada4e8.mle+ocaml@mega-nerd.com> <20070905104127.GB24323@furbychan.cocan.org> <20070905211013.b53cf46b.mle+ocaml@mega-nerd.com> <1188991526.46de922610e05@webmail.in-berlin.de> <200709051215.l85CFqI31114@virtutech.se> In-Reply-To: <200709051215.l85CFqI31114@virtutech.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Miltered: at concorde with ID 46DF177B.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bandel:01 in-berlin:01 bug:01 basename:01 mattias:01 mattias:01 bug:01 python's:01 basename:01 pathname:01 dirname:01 dirname:01 val:01 usr:01 lib:01 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 = # 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