From: Till Varoquaux <till@pps.jussieu.fr>
To: Gerd Stolpmann <info@gerd-stolpmann.de>
Cc: Damien Doligez <damien.doligez@inria.fr>,
caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] RFC: basename, dirname, PR#4549
Date: Tue, 27 Dec 2011 23:50:50 -0500 [thread overview]
Message-ID: <CAHJESt0UM8-gKLXfeguBEnb5zcR5x=_rO1h1Gwyu2PEwFRX1mA@mail.gmail.com> (raw)
In-Reply-To: <1325014940.5036.8.camel@samsung>
Like Gerd pointed out the trailing slash handing in Posix semantic is
there because a/b/x and a/b/x/ point to the same file. When combined
with naive (but correct in a POSIX setting) application you can end-up
with multiple // in the middle of a path (In posix pathname resolution
multiple /'s are treated exactly like single slashes). This can
happen:
let mydir = "/a/b/" in
let myfile = mydir ^ "/myfile" in
now you have myfile = "/a/b//myfile" and (with current ocaml semantic):
basename (basename myfile) = "a/b"
This can be solved by using a clever Filename.concat (the one in
janestreet's core strips out all the extra '.' and '/' around the
concatenation point) but should really be solved in basename/filename.
Till
On Tue, Dec 27, 2011 at 2:42 PM, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> Hi,
>
> I've done a lot of system programming in the past years, and I cannot
> remember that I had to work around this small incompatibility.
>
> Semantically, the POSIX specs are better, because only directories are
> allowed to have trailing slashes, and if you want to get the basename of
> "path/" you want the name of the directory in >99% of the cases. The
> trailing slash has only the meaning that it is asserted that the path
> refers to a directory. And operations like "basename" better ignore such
> assertions.
>
> There could be a problematic area, though: URLs. A trailing slash means
> here a different resource. I don't know whether anybody is using
> basename in this context.
>
> Gerd
>
> Am Dienstag, den 27.12.2011, 17:29 +0100 schrieb Damien Doligez:
>> Hello,
>>
>> I would like to get some comments from the OCaml community at large about
>> the problem raised in http://caml.inria.fr/mantis/view.php?id=4549
>>
>> In a nutshell, the problem is that our version of basename and dirname
>> are not exactly the same as the Open Group's definition.
>>
>> We can easily implement the standard behaviour for basename and dirname,
>> and it seems desirable, but there is a catch: we will have to change
>> the specification of the standard library slightly.
>>
>> Currently, we specify this:
>>
>> [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}.
>>
>> With the Open Group basename and dirname, this becomes false for
>> names that include some trailing slashes, because such slashes
>> are removed by basename. This means that a name "foo/bar/"
>> becomes "foo/bar" when put through
>> [concat (dirname name) (basename name)]
>> and opening "foo/bar" may succeed if it is a file, while
>> opening "foo/bar/" would fail.
>>
>> I would like to know if anyone relies on the precise behaviour
>> documented in the standard library, and for everyone else, would
>> you prefer the old behaviour or the new (standard) behaviour?
>>
>> -- Damien
>>
>>
>
>
>
> --
> Caml-list mailing list. Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
prev parent reply other threads:[~2011-12-28 4:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-27 16:29 Damien Doligez
2011-12-27 17:37 ` Daniel Bünzli
2011-12-27 18:36 ` Markus Mottl
2011-12-27 19:42 ` Gerd Stolpmann
2011-12-28 4:50 ` Till Varoquaux [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHJESt0UM8-gKLXfeguBEnb5zcR5x=_rO1h1Gwyu2PEwFRX1mA@mail.gmail.com' \
--to=till@pps.jussieu.fr \
--cc=caml-list@inria.fr \
--cc=damien.doligez@inria.fr \
--cc=info@gerd-stolpmann.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox