Re: [eclipse-clp-users] canonical_path_bug/2 bug on Windows... again

From: Paulo Moura <>
Date: Tue, 22 May 2012 14:15:33 +0100
Hi Joachim,

Nice to hear from you again.

On 22/05/2012, at 12:16, Joachim Schimpf wrote:

> Paulo Moura wrote:
>> Hi,
>> I'm using ECLiPSe 6.1#112 on Windows 7 64 bits. The built-in predicate canonical_path_bug/2 always seem to return the wrong path when the first argument is an absolute path such as 'C:/Users/' or 'C:\\Users\\'. The returned path always have the current working directory as a prefix. Moreover, if the first argument starts with an environment variable, the variable is not expanded and again the returned path have the current working directory as a prefix. I reported this bug (which was fixed on 5.x) on July 13, 2006.
> Hi Paulo,
> You have overlooked that ECLiPSe internally uses an OS-independent path
> name syntax which employs no separator characters apart from the "/".
> In this syntax, absolute paths always start with a /.
> The ONLY predicate that understands OS-specific path names is
> os_file_name(?EclipseName, ?OSName), which converts between operating
> system syntax and internal Eclipse syntax.  For example, on Windows,
> os_file_name("//C/a/b", "C:\\a\\b") is true.  ALL other built-in
> predicates that accept/return path names, expect/produce the
> simplified internal form.  If you have path names that come in
> OS syntax, you will have to convert them once.
> This is an old (but clean) design decision dating back to the first
> Windows-port of ECLiPSe in the 90s, when there was still much confusion
> about file name syntax in different operating systems.  The kind of "fix"
> you have in mind would break the design.

I find the design sound. In fact, it's a design also adapted by other Prolog compilers. For example, SWI-Prolog provides a similar prolog_to_os_filename/2 built-in predicate (which I use). The only possible issue when using this conversion predicates is when you receive a path, e.g. from a consult/compile/load predicate call, where the user may pass either an operating-system path or a Prolog "internal" path. In my limited test with ECLiPSe 6.1#112, the os_file_name/2 predicate seems behave correctly when the the second argument already uses the internal syntax.

I'm redesigning the Logtalk code that handles operating-system paths to follow more closely this design (the main issue being that only some Prolog compilers provide these conversion predicates).

>  However, I'm open to suggestions
> of how to make things more intuitive and/or nore compatible with other
> systems.

As you know, dealing with file-system is a portability nightmare, specially when considering both POSIX and Windows. The only practical solution will likely be to provide a library that forgoes the native support (from the point-of-view of interface) and provides a portability layer. I have something along these lines in Logtalk:

You may remember contributing to this code in the past. But, currently, the above code is provided as an example of using conditional compilation directives and not as a standard library (this may change on Logtalk 3.x, under development, however). The main reasons are comprehensive testing (specially on Windows), the lack (of up-to-date) binary distributions of the Prolog compilers (e.g. ECLiPSe itself on MacOS X or XSB on Windows), unexpected incompatible changes (e.g. absolute_file_name/2-3 on recent SWI-Prolog and YAP versions), and the commercial nature of some Prolog compilers (I refuse to buy copies given all the work I do for Prolog standardization and to make Logtalk compatible with those compilers). Summarizing what is starting to sound like a rant, such a portable library would need to be actively maintained by the Prolog vendors themselves. I'm skeptical that that will happen any time soon.

Thanks for your support. Cheers,


Paulo Jorge Lopes de Moura, PhD
Assistant Professor
Dep. of Computer Science, University of Beira Interior
6201-001 Covilhã, Portugal

Office 3.18  Ext. 3276
Phone: +351 275 242081 Fax: +351 275 319899
Email: <>

Home page: <>
Research:  <> Blog: <>
Received on Tue May 22 2012 - 13:15:49 CEST

This archive was generated by hypermail 2.2.0 : Thu May 24 2012 - 06:14:26 CEST