Bug in Filename.basename?

Bug in Filename.basename?

[Erik de Castro Lopo]

Hi all,

I think I have found a bug in the above function.
        Objective Caml version 3.10.0

    # let x = Filename.basename "a/b/c" ;;
    val x : string = "c"
    # let x = Filename.basename "a/b/c/" ;;
    val x : string = "."

The first result is fine, but second result is definitely not what
one would reasonably expect.

For instance, the basename program in Linux gives:

    > basename a/b/c/
    c

Erik

-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"C++ is a language strongly optimized for liars and people who
go by guesswork and ignorance." -- Erik Naggum

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

[Richard Jones]

On Wed, Sep 05, 2007 at 06:45:38PM +1000, Erik de Castro Lopo wrote:
> Hi all,
> 
> I think I have found a bug in the above function.
>         Objective Caml version 3.10.0
> 
>     # let x = Filename.basename "a/b/c" ;;
>     val x : string = "c"
>     # let x = Filename.basename "a/b/c/" ;;
>     val x : string = "."
> 
> The first result is fine, but second result is definitely not what
> one would reasonably expect.
> 
> For instance, the basename program in Linux gives:
> 
>     > basename a/b/c/
>     c

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.

Rich.

-- 
Richard Jones
Red Hat

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

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

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

The behaviour of Ocaml's Filename.basename is the same on Linux and
Mac OSX.


Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
http://en.wikipedia.org/wiki/Why_I_Am_Not_a_Christian
http://en.wikipedia.org/wiki/Why_I_Am_Not_a_Muslim
http://en.wikipedia.org/wiki/Strong_atheism

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

[Oliver Bandel]

Zitat von Erik de Castro Lopo <mle+ocaml@mega-nerd.com>:

> 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

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

[Erik de Castro Lopo]

Oliver Bandel wrote:

> But possibly it's not different to other basename-implementations.

Which is exactly what I said later in my email.

> Looking at that documentation, I can't see no bug in the implementation.

Your documentation documents the Ocaml function. 

> 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?

We are not talking about GPS systems or video cameras or vacuum cleaners,
but if you want we can continue; I would be complaining if I was sold
a video camera that didn't record video but did suck a lot of air.

The function is called basename just like the IEEE Std 1003.1 standard
function specified by The Open Group:

    http://www.opengroup.org/onlinepubs/000095399/functions/basename.html

In the examples section of that document they give these examples:

    Input String    Output String
    "/usr/lib"      "lib"
    "/usr/"         "usr"

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Who would have believed that reading and writing would pay
off?"  -- Homer Simpson

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

[Olivier Andrieu]

On 9/5/07, Richard Jones <rich@annexia.org> wrote:
> On Wed, Sep 05, 2007 at 06:45:38PM +1000, Erik de Castro Lopo wrote:
> > Hi all,
> >
> > I think I have found a bug in the above function.
> >         Objective Caml version 3.10.0
> >
> >     # let x = Filename.basename "a/b/c" ;;
> >     val x : string = "c"
> >     # let x = Filename.basename "a/b/c/" ;;
> >     val x : string = "."
> >
> > The first result is fine, but second result is definitely not what
> > one would reasonably expect.
> >
> > For instance, the basename program in Linux gives:
> >
> >     > basename a/b/c/
> >     c
>
> 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.

POSIX has a precise definition of its basename() function:
    http://www.opengroup.org/onlinepubs/009695399/functions/basename.html

and it indeed says that trailing / are to be removed.

-- 
  Olivier

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

[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".

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

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

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

[Brian Hurt]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

Erik de Castro Lopo wrote:

>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.
>  
>
Interesting point from the Linux basename man page:

>        There  are  two  different  versions  of basename() - the POSIX 
> version
>        described above, and the GNU version one gets after
>          #define _GNU_SOURCE
>          #include <string.h>
>        The GNU version never modifies its  argument,  and  returns  
> the  empty
>        string  when  path has a trailing slash, and in particular also 
> when it
>        is "/".  There is no GNU version of dirname().


So there seems to be some confusion, even at Gnu, as to what the proper 
behavior of this function should be.

Brian


[-- Attachment #2: Type: text/html, Size: 1936 bytes --]

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

[Markus E L]

Erik de Castro Lopo wrote:

> 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.
>
> 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"         "."
>
> The behaviour of Ocaml's Filename.basename is the same on Linux and
> Mac OSX.


But

tmp/:$ cat /etc/hosts/
cat: /etc/hosts/: Not a directory

Most shell tools interpret the trailing slash as meaning '[...]/.' .
I'd definitely vote for Linux or Mac OS/X shell basename being buggy
rather than ocamls. Trailing shlashes have meaning (actually I think a
trailing slash should result in a "badly formed path error" but this
convention is probably too deeply entrenched now to fight it).

The standards, though:

 http://www.opengroup.org/onlinepubs/009695399/utilities/basename.html

 - If there are any trailing slash characters in string, they shall be removed.

 http://www.opengroup.org/onlinepubs/009695399/functions/basename.html

 - The same, but only given by example, not by specification

Given how most shell tools interpret trailing slashes I think it's
rather a problem of the standard to introduce inconsistencies in order
to conform to existing practice. In those cases I consider it better
not to orient towards the standard (and who says that OCaml basename
has to work like POSIX or Single Unix basename?).

Regards -- Markus

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

[Markus E L]

Erik de Castro Lopo wrote:

> Oliver Bandel wrote:
>
>> But possibly it's not different to other basename-implementations.
>
> Which is exactly what I said later in my email.
>
>> Looking at that documentation, I can't see no bug in the implementation.
>
> Your documentation documents the Ocaml function. 
>
>> 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?
>
> We are not talking about GPS systems or video cameras or vacuum cleaners,
> but if you want we can continue; I would be complaining if I was sold
> a video camera that didn't record video but did suck a lot of air.
>
> The function is called basename just like the IEEE Std 1003.1 standard
> function specified by The Open Group:
>
>     http://www.opengroup.org/onlinepubs/000095399/functions/basename.html
>
> In the examples section of that document they give these examples:
>
>     Input String    Output String
>     "/usr/lib"      "lib"
>     "/usr/"         "usr"

Yeah, but that function does the wrong thing[tm]. Sorry.

Regards -- Markus

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

[Oliver Bandel]

Zitat von Erik de Castro Lopo <mle+ocaml@mega-nerd.com>:

> Oliver Bandel wrote:
>
> > But possibly it's not different to other basename-implementations.
>
> Which is exactly what I said later in my email.
[...]

No, you showed two examples.
Did you tested other systems/implementations also?


Even if all results are the same, it doesn't matter,
because you compare things that can't be compared.

Switch on your mental type checking ;-)


>
> > Looking at that documentation, I can't see no bug in the implementation.
>
> Your documentation documents the Ocaml function.

Yes, and you asked for the behaviour of the OCaml function,
so I did read the right documentation.

You preassumed, that OCaml's Filename.basename has to implement
a basename-function that you want, but this is nonsense.


>
> > 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?
>
> We are not talking about GPS systems or video cameras or vacuum cleaners,
> but if you want we can continue;
[...]

it seems, that you want to cintinue this.
But it's better to stop it.


> I would be complaining if I was sold
> a video camera that didn't record video but did suck a lot of air.

You better should open your eyes and see that a video camera is not a car.
And that you looked into the wrong manual.


>
> The function is called basename just like the IEEE Std 1003.1 standard
> function specified by The Open Group:
>
>     http://www.opengroup.org/onlinepubs/000095399/functions/basename.html
[...]

This is a C-function. Filename.basename has the same name,
and does a similar thing, but it's an OCaml-function that implements a behaviour
that is described in the OCaml-manual.


If you want the behaviour of
http://www.opengroup.org/onlinepubs/000095399/functions/basename.html
then use it. But you have to program in C for that.

BTW: In your examples you used shells, not C.
This again is wrong, when you compare it with C.

It's more likely to assume that a shell (which shells did you use?
different shells might also bring different results)
is intended to offer the behaviour of the C-functions,
than to assume that OCaml re-implements the shell-behaviour.



>
> In the examples section of that document they give these examples:
>
>     Input String    Output String
>     "/usr/lib"      "lib"
>     "/usr/"         "usr"
[...]

================================================
# Filename.basename "/usr/lib";;
- : string = "lib"
# Filename.basename "/usr/";;
- : string = "."
# Filename.dirname "/usr/lib";;
- : string = "/usr"
# Filename.dirname "/usr/";;
- : string = "/usr"
#
================================================

"/usr/" is a directory. So, Filename.dirname should give "usr".

The behaviour of OCaml's
  Filename.concat (Filename.dirname) (Filename.basename)
makes sense to me. IMHO it should be done the way OCaml does it.
And the documentation and the Implementation do not differ.
So, this is fine.
If you mean a directory, append "/", if it is a file, not use a "/" at the end.

So, the OCaml-behaviour IMHO makes sense wonderfully.

Ciao,
   Oliver

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

[Oliver Bandel]

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

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

[Oliver Bandel]

Zitat von Oliver Bandel <oliver@first.in-berlin.de>:
[...]
>
> ================================================
> # Filename.basename "/usr/lib";;
> - : string = "lib"
> # Filename.basename "/usr/";;
> - : string = "."
> # Filename.dirname "/usr/lib";;
> - : string = "/usr"
> # Filename.dirname "/usr/";;
> - : string = "/usr"
> #
> ================================================
>
> "/usr/" is a directory. So, Filename.dirname should give "usr".
>
[...]

No, this is a typo: it should give "/usr", as it does. :)

Ciao,
  Oliver

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

[skaller]

On Wed, 2007-09-05 at 22:39 +0200, Oliver Bandel wrote:

> The behaviour of OCaml's
>   Filename.concat (Filename.dirname) (Filename.basename)
> makes sense to me. IMHO it should be done the way OCaml does it.

You fail to understand that this requirement is ALSO
met by Posix C functions and bash.

The difference is Ocaml's function doesn't have well specified
semantics, whereas Posix is an International Standard backed
by the United Nations.

The Ocaml manual says this:

http://caml.inria.fr/pub/docs/manual-ocaml/libref/Filename.html

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

And that is in fact rubbish: filename functionality is not
directly related to the filesystem, because the files need
not exist (or may not agree with the specified name in kind).

Other than this text, the Ocaml manual in fact does NOT
specify what happens if there is a trailing / character.

Posix does. So you're wrong on all counts here.
There's no excuse for Ocaml not doing one of:

	a) following the Posix rules on a Posix platform
	   AND saying so
	b) following other rules, AND describing them

In general, a WEAK specification is good, and the Ocaml
specification here is weak: it doesn't specify what happens
if there is a trailing / character. However in THIS case
the user may be surprised at what it actually does.

Indeed, the OP Eric was surprised!

The fact is I AGREE WITH YOUR ARGUMENT if you would be arguing
that it is sensible to consider that since in Unix you cannot
tell if a filename refers to a directory or a non-directory file,
a SENSIBLE CONVENTION is to put a / at the end if you mean a 
directory.

I agree, that's sensible. But it doesn't matter. The purpose
of the Filename module is to process filenames in a way that
closely matches the normal behaviour of native functions on
the native platform .. and the interpretation above IS NOT DOCUMENTED.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

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

[Christophe Raffalli]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Dear list members,

I think that Filename.basename "a/b/c/" should return "c/" because
ìf you write a trailing slash you meant that the filename represents a directory and this
information should be preserved and accounted by all Unix and Filename calls so that your
code can answer "this is not a directory" in some places.


- --
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
- ---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature. The public key is
stored on www.keyserver.net
- ---------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG36fFi9jr/RgYAS4RAkV2AJ4kA1/aeaA8YdRTaxbsmFgVQ1GC5ACfTIXZ
IjQXaTvzCX7vXyFSFUwnR4I=
=ixCX
-----END PGP SIGNATURE-----

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

[Markus E L]

Oliver Bandel wrote:

> It's more likely to assume that a shell (which shells did you use?
> different shells might also bring different results)

Not quite: Basename is an external command .

   tmp/:$ which basename
   /usr/bin/basename

POSIX/Single Unix docuements it as having the same behaviour as the C
function (actually it doesn't say so explicitely but both are
described in different ways which boil down to the same behaviour).

> is intended to offer the behaviour of the C-functions,
> than to assume that OCaml re-implements the shell-behaviour.

But basically I'm d'accord regarding that Filename.basename is just a
different thing.


Regards -- Markus

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

[Oliver Bandel]

Zitat von skaller <skaller@users.sourceforge.net>:

> On Wed, 2007-09-05 at 22:39 +0200, Oliver Bandel wrote:
>
> > The behaviour of OCaml's
> >   Filename.concat (Filename.dirname) (Filename.basename)
> > makes sense to me. IMHO it should be done the way OCaml does it.
>
> You fail to understand that this requirement is ALSO
> met by Posix C functions and bash.
[...]

But that does not mean that OCaml does not make it.
So, what's the problem?


>
> The difference is Ocaml's function doesn't have well specified
> semantics, whereas Posix is an International Standard backed
> by the United Nations.

Maybe OCaml later will be also ;-)
BTW: specify "United Nations", it could be misleading, what you are writing.
I didn't know that the UNO makes programming language standardization.


>
> The Ocaml manual says this:
>
> http://caml.inria.fr/pub/docs/manual-ocaml/libref/Filename.html
>
> "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.
>
> And that is in fact rubbish:

Yes and No.

> filename functionality is not
> directly related to the filesystem,

correct.

> because the files need
> not exist (or may not agree with the specified name in kind).

If you read again, you can see: "references to basename (...)
 name designate the same file as name before the call to Sys.chdir".
The term "references" might be misleading, but what is meant?

Possibly the result of Sys.readdir, so this means that the
names one has got from one function of the Filename module
are also useful, after using Sys.chdir, because Sys.readdir gives
you the basenames of the files in the dir you read.

If you compare functionality of functions of a module,
look, what functionality the module also offers.
Looking somewhere else makes no sense. This would be
ignoring the sense of modularization.
Inconsistencies in one and the same module would be a reason to
argue about.


>
> Other than this text, the Ocaml manual in fact does NOT
> specify what happens if there is a trailing / character.

If this is the problem, then the documentation should be
more verbose.


>
> Posix does. So you're wrong on all counts here.
> There's no excuse for Ocaml not doing one of:
>
> 	a) following the Posix rules on a Posix platform
> 	   AND saying so
> 	b) following other rules, AND describing them

The documentation then should be made more clear.
But to say, that OCaml has a bug, only because it does
not handle things equally like the POSIX-stuff, which btw
uses C-functions....

If POSIX should be followed completely, then it also has to follow in this way:

  http://www.opengroup.org/onlinepubs/009695399/functions/basename.html

  "The basename() function may modify the string pointed to by path,
    and may return a pointer to static storage that may then be
    overwritten by a subsequent call to basename()."

It may ,modify, it may not.

So, I doubt this is something that you want to have in OCaml's
Filename-module. If it is not mentioned that things might be
modified in place, in a mostly-functional language I want to have
the arguments not modified.

Following POSIX here, would posbe a desaster.


>
> In general, a WEAK specification is good, and the Ocaml
> specification here is weak: it doesn't specify what happens
> if there is a trailing / character. However in THIS case
> the user may be surprised at what it actually does.

If this is a point that is unclear, write a note on the bugtracker,
to make the documentation more clear.

>
> Indeed, the OP Eric was surprised!

Maybe. But why to blame OCaml as buggy, if he is surprised?

OCaml handles a lot of things in a different way.
Or were are e.g. sumtypes in POSIX defined?

I rather would argue into the  opposite direction:
a Unix.fork() should not give back an int, only because on Unix/POSIX this
is done this way. Beter would be something like

type fork_t = Parent | Child of int

where int means the PID.

It's too-much POSIX/Unix here, IMHO, even if it is called
the Unix-module.

But it's not a reason to make long discussions on it.
I would like it differently, but it also is acceptable as it is.



>
> The fact is I AGREE WITH YOUR ARGUMENT if you would be arguing
> that it is sensible to consider that since in Unix you cannot
> tell if a filename refers to a directory or a non-directory file,
> a SENSIBLE CONVENTION is to put a / at the end if you mean a
> directory.

This would be fine, to make it always this way.
This would be clear then.
Not all people would follow this.

The advantage of making all things a file has the disadvantage
that the name allone could not show us, what kind of file it is.
For that reason, the filetype can be distingushed by the results of Unix.stat.



>
> I agree, that's sensible. But it doesn't matter. The purpose
> of the Filename module is to process filenames in a way that
> closely matches the normal behaviour of native functions on
> the native platform


That's your interpretation.
The documentation of Filename-module msays:

===================
module Filename: sig .. end

Operations on file names.
===================


That's not much ;-)


> .. and the interpretation above IS NOT DOCUMENTED.

In the documentation of the Filename-module I can't see
that they say, they Follow POSIX. So, YOUR ASSUMPTION
might be a problem.


I'm happy not to have too much POSIX-behaviour inside OCaml,
when for example, regarding the modified strings of the args.

But maybe you would like it that way.

Ciao,
   Oliver

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

[Oliver Bandel]

Zitat von Markus E L <ls-ocaml-2006@m-e-leypold.de>:

>
> Oliver Bandel wrote:
>
> > It's more likely to assume that a shell (which shells did you use?
> > different shells might also bring different results)
>
> Not quite: Basename is an external command .
>
>    tmp/:$ which basename
>    /usr/bin/basename
[...]

Yes, that's correct.
But you could implement your own basename in a shell.
And in a typed shell you will have to.



>
> POSIX/Single Unix docuements it as having the same behaviour as the C
> function (actually it doesn't say so explicitely but both are
> described in different ways which boil down to the same behaviour).
>
> > is intended to offer the behaviour of the C-functions,
> > than to assume that OCaml re-implements the shell-behaviour.
>
> But basically I'm d'accord regarding that Filename.basename is just a
> different thing.
[...]

Otherwise, a planetary registering of function-/method-names
Should be done... never name a method or function the same way, others does..
Then we would have a global/planetary society of function-name registering.

Possibly we would name them like the regristration plate of cars. ;-)

Each function name must be uniqe, Polymorphism forbidden. ;-)

Ciao,
   Oliver