Hi,
The change I just tested was
my @libs = ();
for my $ilib ( @INC ) {
$ilib =~ s/\\$/\\\\/;
push(@libs, qq(-I\"$ilib\") );
}
I chose this route purely to be consistent with the implementation in
Module::ScanDeps::DataFeed.
(Which is not explicitly MSWin specific). The thinking here is that fixes for
problems that are exposed by usage of either module can be applied to both.
I chose an implementation without 'map' as I have an unreasonable antipathy
towards it :-)
However, as all suggestions will 'work' for the specific case in question. I
have no preference.
Steffen, as maintainer the choice is yours. I'll test build and patch whichever
method decided upon.
For info, the history of this begins with PAR::Packer 0.960 where the
implementation was:
my @libs = (map {"-I$_"} @INC);
This does not handle paths with spaces so was changed in 0.970 to:
my @libs = (map {"-I\"$_\""} @INC);
Regards
Mark
Steven Mackenzie wrote:
> Hello,
>
> Sorry to go quiet on the thread that I started, and thanks for all the
> debugging!
>
> I would amend Dr Ruud's suggestion as below:
> if ($^O =~ /^MSWin/) {
> s{\\$}{}g for @libs;
> }
>
> 1/ The $^O check at the head of the block is clearer (for me) to read - the
> flow
> of the code is such that you can skip reading the block if you aren't
> interested
> in the MSWin case, rather than trying to understand what is happening, and
> then
> noticing "Oh, it's MSWin only"
>
> 2/ *Removing* only the trailing \ instead of replacing with / means that all
> slashes within a single path are consistent, and minimally changed from the
> value read from the environment, and it works.
>
>
> Steven
>
>
> Mark Dootson wrote:
>> Hi,
>>
>> I limited to just the trailing backslash because I was confident that that
>> would work in all cases I know of.
>>
>> I'm not sure if '//server/share' would work nor am I entirely confident I've
>> thought of all the ways a path can be constructed in the Windows/Samba
>> world. I am as confident as one can be that just changing the trailing
>> backslash would work.
>>
>> I took a look at Module::ScanDeps::DataFeed which is another module where
>> the trailing backslash issue is addressed. That module escapes the trailing
>> slash with
>>
>> join(',', map("\n\t'$_'", map {s/\\$/\\\\/; $_} @inc));
>>
>> I have no preference between the two methods, but as the two modules are
>> often used together, would it be a good idea to take a common approach in
>> both modules?
>>
>> I will prepare/test patch that escapes the trailing backslash in Base.pm and
>> post + apply.
>>
>> Regards
>>
>> Mark
>>
>>
>>
>>
>>
>> Steffen Mueller wrote:
>>> Hi Mark,
>>>
>>> Mark Dootson schrieb:
>>>> Is it possible to have full UNC paths in @INC?
>>>> For this and other cases the attached patch works too.
>>> For those not in the know: UNC paths are mostly the \\Server\Share\Dir
>>> syntax commonly seen in Windows/Samba shares. To be entirely honest, I
>>> had to look that up. :)
>>>
>>> I never really thought about this. I would guess such paths break all
>>> kinds of regular expressions in various places. Not just in PAR and its
>>> companion modules but perhaps also in perl itself, File::Spec, etc.
>>>
>>> But it's something to keep in mind. Better to be safe than sorry.
>>>
>>> About the code:
>>> Why s/\\+$/\//? Is replacing just a trailing backslash with a slash a
>>> good idea? s/\\/\/g would have done, too, wouldn't it? (perl doesn't
>>> care about / vs \ in paths.) Or removing any trailing (back-)slash in
>>> the first place: s/(?:\\|\/)$//?
>>>
>>> I think your patch isn't clumsy at all. "elegant", "one-line",
>>> "readable", pick two. :)
>>>
>>> I assume you did the replacement of just one path separator in order to
>>> change the string as little as possible, after all c:\foo\ is
>>> semantically more similar to c:\foo/ than to c:\foo.
>>>
>>> Can you apply your patch yourself?
>>>
>>> Steffen
>>>
>>
