Bug #92578 for Win32-FetchCommand: Win32::FetchCommand Test Failure

Thu Jan 30 06:29:05 2014 Smylers [...] stripey.com - Ticket created

Subject:	Win32::FetchCommand Test Failure
Date:	Thu, 30 Jan 2014 11:28:51 +0000
To:	bug-Win32-FetchCommand [...] rt.cpan.org
From:	Smylers <Smylers [...] stripey.com>

Hi there. Thank you for producing Win32::TestCommand. Unfortunately it seems that its tests fail on recent perls — though after installing it without tests, the module itself still seems to be working fine (at least for my situation). I was trying on Strawberry Perl v5.14. It looks like it hasn't worked for any Cpan Testers on that or any more recent versions: http://www.cpantesters.org/distro/W/Win32-FetchCommand.html#Win32-FetchCommand-0.04?oncpan=1&distmat=1 The first test that fails for me is this one: # The only appln we can be certain of is perl! $^E = 0; my @Cmd = FetchCommand ('config.pl'); ok(!$^E, 'os ext.error ok'); The FetchCommand returns the empty list, and $^E is set to “The system could not find the environment option that was entered”. Ironically, .pl is the only extension I've found that FetchCommand doesn't return the expected application. It works for .txt, .pdf, and so on. In Explorer my .pl files do have a camel icon, and running one from a command prompt does invoke perl.exe on it. So it appears that .pl is associated correctly on this system, but possibly it's done in some other way than .txt and others have been done. Either FetchCommand needs fixing so it manages to find perl.exe for .pl files again, or those tests need skipping so the module can straightforwardly be installed. Cheers Smylers -- http://twitter.com/Smylers2

Thu Jan 30 15:35:55 2014 clive_darke [...] yahoo.co.uk - Correspondence added

Subject:	Re: [rt.cpan.org #92578] Win32::FetchCommand Test Failure
Date:	Thu, 30 Jan 2014 20:32:43 +0000 (GMT)
To:	"bug-Win32-FetchCommand [...] rt.cpan.org" <bug-Win32-FetchCommand [...] rt.cpan.org>
From:	Clive Darke <clive_darke [...] yahoo.co.uk>

Thanks for the heads-up, I'll try to find time to look into it. Cheers, Clive On Thursday, 30 January 2014, 11:29, "Smylers@stripey.com via RT" <bug-Win32-FetchCommand@rt.cpan.org> wrote: Thu Jan 30 06:29:05 2014: Request 92578 was acted upon. Transaction: Ticket created by Smylers@stripey.com Queue: Win32-FetchCommand Subject: Win32::FetchCommand Test Failure Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: Smylers@stripey.com Status: new Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=92578> Hi there. Thank you for producing Win32::TestCommand. Unfortunately it seems that its tests fail on recent perls — though after installing it without tests, the module itself still seems to be working fine (at least for my situation). I was trying on Strawberry Perl v5.14. It looks like it hasn't worked for any Cpan Testers on that or any more recent versions: http://www.cpantesters.org/distro/W/Win32-FetchCommand.html#Win32-FetchCommand-0.04?oncpan=1&distmat=1 The first test that fails for me is this one: # The only appln we can be certain of is perl! $^E = 0; my @Cmd = FetchCommand ('config.pl'); ok(!$^E, 'os ext.error ok'); The FetchCommand returns the empty list, and $^E is set to “The system could not find the environment option that was entered”. Ironically, .pl is the only extension I've found that FetchCommand doesn't return the expected application. It works for .txt, .pdf, and so on. In Explorer my .pl files do have a camel icon, and running one from a command prompt does invoke perl.exe on it. So it appears that .pl is associated correctly on this system, but possibly it's done in some other way than .txt and others have been done. Either FetchCommand needs fixing so it manages to find perl.exe for .pl files again, or those tests need skipping so the module can straightforwardly be installed. Cheers Smylers -- http://twitter.com/Smylers2

Thu Jan 30 15:35:56 2014 The RT System itself - Status changed from 'new' to 'open'

Wed Feb 05 11:32:39 2014 Smylers [...] stripey.com - Correspondence added

Subject:	Re: [rt.cpan.org #92578] AutoReply: Win32::FetchCommand Test Failure
Date:	Wed, 5 Feb 2014 16:32:24 +0000
To:	Bugs in Win32-FetchCommand via RT <bug-Win32-FetchCommand [...] rt.cpan.org>
From:	Smylers <Smylers [...] stripey.com>

I wrote: Show quoted text

> In Explorer my .pl files do have a camel icon, and running one from a > command prompt does invoke perl.exe on it. So it appears that .pl is > associated correctly on this system, but possibly it's done in some > other way than .txt and others have been done.

I checked the file-type associations for .pl, and ftype claims not to know what to do with it: C:>assoc .pl .pl=Perl_program_file C:>ftype Perl_program_file File type 'Perl_program_file' not found or no open command associated with it. However, in Windows Explorer, double-clicking the file opens it with perl.exe. And indeed typing something like zap.pl at the prompt also runs perl.exe on it. So it looks like Windows itself gets confused about file associations, or has two different lists of them or something. This computer has had ActivePerl, DwimPerl, and Strawberry Perl installed, and then ActivePerl uninstalled; any of those installers and uninstallers could've fiddled with the file associations, so it's possible that I have a particularly non-standard set-up. However, the Cpan Testers failures suggest that a default Strawberry Perl installation is also affected by this. Good luck with tracking it down. Smylers -- http://twitter.com/Smylers2

Wed Feb 05 13:21:45 2014 clive_darke [...] yahoo.co.uk - Correspondence added

Subject:	Re: [rt.cpan.org #92578] AutoReply: Win32::FetchCommand Test Failure
Date:	Wed, 5 Feb 2014 18:21:34 +0000 (GMT)
To:	"bug-Win32-FetchCommand [...] rt.cpan.org" <bug-Win32-FetchCommand [...] rt.cpan.org>
From:	Clive Darke <clive_darke [...] yahoo.co.uk>

Thanks for the extra info. The original CPAN tests were failing because they had not done any file association. Cheers, Clive On Wednesday, 5 February 2014, 16:32, "Smylers@stripey.com via RT" <bug-Win32-FetchCommand@rt.cpan.org> wrote: Queue: Win32-FetchCommand Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=92578> I wrote: Show quoted text

> In Explorer my .pl files do have a camel icon, and running one from a > command prompt does invoke perl.exe on it. So it appears that .pl is > associated correctly on this system, but possibly it's done in some > other way than .txt and others have been done.

I checked the file-type associations for .pl, and ftype claims not to know what to do with it: C:>assoc .pl .pl=Perl_program_file C:>ftype Perl_program_file File type 'Perl_program_file' not found or no open command associated with it. However, in Windows Explorer, double-clicking the file opens it with perl.exe. And indeed typing something like zap.pl at the prompt also runs perl.exe on it. So it looks like Windows itself gets confused about file associations, or has two different lists of them or something. This computer has had ActivePerl, DwimPerl, and Strawberry Perl installed, and then ActivePerl uninstalled; any of those installers and uninstallers could've fiddled with the file associations, so it's possible that I have a particularly non-standard set-up. However, the Cpan Testers failures suggest that a default Strawberry Perl installation is also affected by this. Good luck with tracking it down. Smylers -- http://twitter.com/Smylers2