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
>>
>
>
