| Subject: | Test::Harness changes @INC on Windows |
I noticed a change in @INC with Test-Harness 3 in maint-5.10:
The directories in @INC on Windows are derived from the location of the
Perl binary (stored in $^X). The function
TAP::Parser::Source::Perl::_get_perl() runs Win32::GetShortPathName() on
$^X before returning it (most likely to try to remove any spaces in the
filename to the perl.exe executable). It then uses this modified $^X
value to run perl.exe for the actual tests.
This however also changes the @INC entries in the perl.exe subprocess to
use the short pathnames:
C:\>"C:\My Perl\bin\perl.exe" -E "say for $^X, @INC"
C:\My Perl\bin\perl.exe
C:/My Perl/site/lib
C:/My Perl/lib
.
C:\>C:\MYPERL~1\bin\perl.exe -E "say for $^X, @INC"
C:\MYPERL~1\bin\perl.exe
C:/MYPERL~1/site/lib
C:/MYPERL~1/lib
.
I don't really like this change (from Test-Harness 2) as it makes it
harder to use Test-Harness to check if a module works correctly when
perl.exe is installed in a directory name with a space in it, giving you
a false sense of security.
And it would not be correct to rely on the result of
Win32::GetShortPathName() not to include any spaces as the generation of
short names can be disabled for NTFS, and there may be filesystems that
don't even support short names.
Is there a good reason not to get rid of this line in _get_perl():
return Win32::GetShortPathName($^X) if IS_WIN32;