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 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 70381BC6B for ; Wed, 5 Sep 2007 13:25:29 +0200 (CEST) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l85BPSDo019830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Sep 2007 13:25:29 +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 l85BPQI6031377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 5 Sep 2007 13:25:27 +0200 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id l85BPQE4031370 for caml-list@inria.fr; Wed, 5 Sep 2007 13:25:26 +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 13:25:26 +0200 Message-ID: <1188991526.46de922610e05@webmail.in-berlin.de> Date: Wed, 5 Sep 2007 13:25:26 +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> In-Reply-To: <20070905211013.b53cf46b.mle+ocaml@mega-nerd.com> 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 discorde with ID 46DE9228.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 ocaml:01 ocaml:01 basename:01 ocaml's:01 bug:01 val:01 dirname:01 dirname:01 chdir:01 chdir:01 wrote:01 Zitat von Erik de Castro Lopo : > Richard Jones wrote: > > > I think the OCaml one is what I'd reasonably expect actually. > > > > The GNU documentation for basename says: > > > > `basename' removes any leading directory components from NAME. > > > > and a/b/c/ are leading directory components. > > The word "leading" in the above is at best, ambiguous. > > Regardless of what the documentation says, the behaviour of Ocaml's > basename function is different from the basename program (from the > GNU coreutils package) on my Linux system. [...] But possibly it's not different to other basename-implementations. Do you think *your* current basename should be the way, all other people should go, when implementing a function that has the same name and a similar functionality? What, if your basename-implemantation is buggy? Should all other people rewrite a buggy thing? > > Since I suspect that the basename function is meant to emulate the > basename program I see the Ocaml function's behaviour as a bug. I > would however discount this if the behaviour of basename on some > other commonly used system (eg *BSD) matched the Ocaml behaviour. > > However, here is a comparison chart of what I have tested so far: > > "a/b/c" "a/b/c/" > Linux basename "c" "c" > Mac OSX basename "c" "c" > Ocaml Filename.basename "c" "." [...] It doesn't matter. It even doesn't matter that Filename.basename might be correct, when loohing at the basename-documentation. You (both) have to look in the OCaml-documentation, if you think it might be buggy. When you look there, you find this: ====================================================================== val basename : string -> string Split a file name into directory name / base file name. concat (dirname name) (basename name) returns a file name which is equivalent to name. Moreover, after setting the current directory to dirname name (with Sys.chdir), references to basename name (which is a relative file name) designate the same file as name before the call to Sys.chdir. The result is not specified if the argument is not a valid file name (for example, under Unix if there is a NUL character in the string). ====================================================================== Looking at that documentation, I can't see no bug in the implementation. When you want to know how your car's GPS-navigation system works, do you look in the documentation of your video-camera or vacuum-cleaner? And if you then drive in the wrong direction, who do you will blame for that? Ciao, Oliver