Bug #115518 for Moo: Moo-2.002002 fails to build due to hard coded directory separator

Tue Jun 21 16:04:08 2016 nanis [...] cpan.org - Ticket created

Subject:	Moo-2.002002 fails to build due to hard coded directory separator
Date:	Tue, 21 Jun 2016 16:03:58 -0400
To:	bug-Moo [...] rt.cpan.org
From:	"A. Sinan Unur" <nanis [...] cpan.org>

I get this: C:\...\Moo-2.002002> nmake test Microsoft (R) Program Maintenance Utility Version 12.00.21005.1 Copyright (C) Microsoft Corporation. All rights reserved. "C:\opt\perl\5.24.0\bin\perl.exe" -It/lib -MTestEnv= "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t\*.t Can't open perl script "/lib": No such file or directory NMAKE : fatal error U1077: 'C:\opt\perl\5.24.0\bin\perl.exe' : return code '0x2' Stop. The offending shell command is generated in `sub test_via_harness`. While Windows APIs are indifferent as to whether one uses / or \ to separate directory names in paths, / can be misinterpreted as the start of a command line argument when arguments are passed through a shell. HTH -- Sinan

Tue Jun 21 16:05:58 2016 nanis [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #115518] Moo-2.002002 fails to build due to hard coded directory separator
Date:	Tue, 21 Jun 2016 16:05:49 -0400
To:	bug-Moo [...] rt.cpan.org
From:	"A. Sinan Unur" <nanis [...] cpan.org>

Apologies, the subject should have said "cannot run tests" instead of "fails to build". -- Sinan

Thu Jun 23 19:40:38 2016 haarg [...] haarg.org - Correspondence added

The actual problem is that nmake corrupts any uses of / in commands, and has nothing to do with directory separators. Fixed in 2.003002.

Thu Jun 23 19:40:40 2016 The RT System itself - Status changed from 'new' to 'open'

Thu Jun 23 19:40:46 2016 haarg [...] haarg.org - Status changed from 'open' to 'resolved'

Fri Jun 24 06:25:17 2016 nanis [...] cpan.org - Correspondence added

CC:	"A. Sinan Unur" <nanis [...] cpan.org>
Subject:	Re: [rt.cpan.org #115518] Moo-2.002002 fails to build due to hard coded directory separator
Date:	Fri, 24 Jun 2016 06:24:58 -0400
To:	bug-Moo [...] rt.cpan.org
From:	"A. Sinan Unur" <nanis [...] cpan.org>

On Thu, Jun 23, 2016 at 7:40 PM, Graham Knop via RT <bug-Moo@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=115518 > > > The actual problem is that nmake corrupts any uses of / in commands, and has nothing to do with directory separators. > > Fixed in 2.003002.

I recommend using canonical path names with external utilities because it a priori rules out a whole lot of problems. Sticking with that simple rule means the programmer does not have to think if an external Windows utility will correctly handle *nix style paths. In this instance, there was a hard-coded *nix path given to an external utility which exposed a bug in it. The external utility is out of our control, but what is passed to it is. That's all. Thank you for your work on Moo. I don't always use OO sugar in Perl, but when I do, I use Moo. -- Sinan

Fri Jun 24 08:07:09 2016 ARISTOTLE [...] cpan.org - Correspondence added

On Fri Jun 24 06:25:17 2016, nanis@cpan.org wrote: Show quoted text

> Sticking with that > simple rule means the programmer does not have to think if an external > Windows utility will correctly handle *nix style paths. In this > instance, there was a hard-coded *nix path given to an external > utility which exposed a bug in it. The external utility is out of our > control, but what is passed to it is.

So if nmake had mangled “http://example.org/somefile.tgz“ into “http: //example.org/somefile.tgz” instead of “t/something.t” into “t /something.t”, your point would have been… what exactly?

Fri Jun 24 08:41:59 2016 nanis [...] cpan.org - Correspondence added

CC:	"A. Sinan Unur" <nanis [...] cpan.org>
Subject:	Re: [rt.cpan.org #115518] Moo-2.002002 fails to build due to hard coded directory separator
Date:	Fri, 24 Jun 2016 08:41:44 -0400
To:	bug-Moo [...] rt.cpan.org
From:	"A. Sinan Unur" <nanis [...] cpan.org>

On Fri, Jun 24, 2016 at 8:07 AM, Aristotle Pagaltzis via RT <bug-Moo@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=115518 > > So if nmake had mangled “http://example.org/somefile.tgz“ into “http: //example.org/somefile.tgz” instead of “t/something.t” into “t /something.t”, your point would have been… what exactly?

Command line arguments containing certain special characters need to be quoted. But, that's neither here nor there. No URL was passed on the command line. On the other hand, file paths are passed around all the time and there are many interesting problems they may cause owing to the legacy of `/` being used to indicate the start of a command line switch/argument on DOS/Windows systems. So, sticking with the "use canonical paths when dealing with other programs" is a good rule to follow. This is kind of like not texting while crossing a street: Sure, pedestrians may have right of way, but it does not hurt to watch out for what people in cars may do. I am not trying to engage in a hypothetical argument. I am glad Moo builds and installs without intervention again and that's all I was interested in. Thank you. -- Sinan

Fri Jun 24 12:26:23 2016 haarg [...] haarg.org - Correspondence added

On Fri Jun 24 06:25:17 2016, nanis@cpan.org wrote: Show quoted text

> On Thu, Jun 23, 2016 at 7:40 PM, Graham Knop via RT <bug- > Moo@rt.cpan.org> wrote:

> > <URL: https://rt.cpan.org/Ticket/Display.html?id=115518 > > > > > The actual problem is that nmake corrupts any uses of / in commands, > > and has nothing to do with directory separators. > > > > Fixed in 2.003002.

> > I recommend using canonical path names with external utilities because > it a priori rules out a whole lot of problems. Sticking with that > simple rule means the programmer does not have to think if an external > Windows utility will correctly handle *nix style paths. In this > instance, there was a hard-coded *nix path given to an external > utility which exposed a bug in it. The external utility is out of our > control, but what is passed to it is. > > That's all. > > Thank you for your work on Moo. I don't always use OO sugar in Perl, > but when I do, I use Moo. > > -- Sinan

The slash wasn't being passed to an external utility. It was being passed to perl. This has absolutely nothing to do with directory separators. nmake has broken handling of slash characters, no matter what purpose you are using them for.