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

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

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