Canonicalize bug?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Canonicalize bug?

Juan Pablo Carbajal-2
Dear gnulib devs,

In the GNU Octave community with run into a problem with canonicalize functions.
It is not clear yet, but it seems that '/' is used for path regardless
of the platform.
One of our devs, Rik, reported this recently

https://savannah.gnu.org/bugs/?45816#comment3

Is this a bug in gnulib?

Thanks

Reply | Threaded
Open this post in threaded view
|

Re: Canonicalize bug?

Dmitri A. Sergatskov


On Mon, Aug 31, 2015 at 4:07 AM, Juan Pablo Carbajal <[hidden email]> wrote:
Dear gnulib devs,

In the GNU Octave community with run into a problem with canonicalize functions.
It is not clear yet, but it seems that '/' is used for path regardless
of the platform.
One of our devs, Rik, reported this recently

https://savannah.gnu.org/bugs/?45816#comment3

Is this a bug in gnulib?

Thanks


​Why it is a problem? I thought windows can use "\" and "/" interchangeably.​
 
​I.e. ​ans = D:\folderA/folderB/file_a.txt is a correct PATH in windows.

Dmitri.
--




Reply | Threaded
Open this post in threaded view
|

Re: Canonicalize bug?

Paul Eggert
In reply to this post by Juan Pablo Carbajal-2
Juan Pablo Carbajal wrote:
> Is this a bug in gnulib?

Do you have file systems where '/' does not work to separate file name
components?  Like VMS or something?  If so, it's a problem, though I'm not sure
it's a bug, as most of gnulib doesn't claim to port to VMS.  If not, then I
don't see the problem.

Reply | Threaded
Open this post in threaded view
|

Re: Canonicalize bug?

John W. Eaton
Administrator
On 08/31/2015 09:54 AM, Paul Eggert wrote:
> Juan Pablo Carbajal wrote:
>> Is this a bug in gnulib?
>
> Do you have file systems where '/' does not work to separate file name
> components?  Like VMS or something?  If so, it's a problem, though I'm
> not sure it's a bug, as most of gnulib doesn't claim to port to VMS.  If
> not, then I don't see the problem.
>

No, we are not supporting VMS.

It doesn't matter much to me personally, but I think some people would
like to see the result contain only \ on Windows systems.

We could always post-process the result, but would you accept a patch
that makes this change inside the gnulib function?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Canonicalize bug?

Paul Eggert
John W. Eaton wrote:
> No, we are not supporting VMS.
>
> It doesn't matter much to me personally, but I think some people would like to
> see the result contain only \ on Windows systems.
>
> We could always post-process the result, but would you accept a patch that makes
> this change inside the gnulib function?

Some people like backslashes, some like slashes, and if we change it to use
backslashes we'll annoy the latter.  Maybe a postpass is a better option.

Reply | Threaded
Open this post in threaded view
|

Re: Canonicalize bug?

PhilipNienhuis
In reply to this post by Dmitri A. Sergatskov
Dmitri A. Sergatskov wrote
On Mon, Aug 31, 2015 at 4:07 AM, Juan Pablo Carbajal <[hidden email]>
wrote:

> Dear gnulib devs,
>
> In the GNU Octave community with run into a problem with canonicalize
> functions.
> It is not clear yet, but it seems that '/' is used for path regardless
> of the platform.
> One of our devs, Rik, reported this recently
>
> https://savannah.gnu.org/bugs/?45816#comment3
>
> Is this a bug in gnulib?
>
> Thanks
>
>
​Why it is a problem? I thought windows can use "\" and "/"
interchangeably.​

​I.e. ​ans = D:\folderA/folderB/file_a.txt is a correct PATH in windows.
You git it (a little bit) wrong in  two ways:

1.  '\' and '/' cannot be entered interchangeably everywhere in Windows:

-   "/' fileseps work fine in MSYS / Mingw and -to some extent- in windows explorer.

-  cmd.exe / cmd32.exe (Windows'  "shell") only accepts '\' fileseps.  Moreover, '/' is an option/parameter prefix there, much like '-' in *nix.  
AFAIU Octave's CLI is based on cmd32.exe but admittedly I do not know how far it inherits cmd32 idiosyncrasies.

2.  (the more creepy issue)  If Octave harvests path names on Windows it usually gets backslash fileseps (i.e, like in "pwd").
If these are mixed in a next step with forward slash fileseps, using e.g., canonicalize_file_name(), problems may occur.
That is exactly the gist of bug #45816.

Philip