6
votes

I like the Vista style for pathing, so on a XP machine I've created NTFS junctions C:\Users -> C:\Documents and Settings and ~\Documents -> ~\My Documents, so that I only ever have to write one style of path C:\Users\me\Documents.

However, CPAN::SQLite and Exporter have a hairy fit when I set PERL5LIB to 'C:\Users\me\Documents\dev\perl\lib'. Exporter's Modules that inherit from Exporter start complaining that export_to_level is not defined when they try to use it.

I really think it's Exporter et al., and CPAN::SQLite is just a victim, because it imports the $dbh symbol in the use statement, only to have perl complain that $dbh was not defined. On top of this, XS-related modules complain that there is no 'bootstrap' method.

So does any one know if Perl (Strawberry) has a particular problem with NTFS Junctions?

1
Could you give actual error messages. (Actual code would be nice too.) I find it hard to believe that Exporter complains about export_to_level not being defined when Exporter never calls it. In fact, it provides it!ikegami
Pyhon eats my Windows XP symbolic links well. Java also. Apache web server - also. I am not a pearl man, but may i ask: did you try the same piece of configuration but giving Docume~1. What tool are you using to make a link. I may assume you are using the Junction. The point is Windows XP is POSIX compatible system. The other point is that saying to file system change directory to C:\Users is interpreted as C:\Documents and Settings on a low kernel level which has nothing to what application isauthor of the call, perl, python whatever.Pavlonator

1 Answers

1
votes

This is not so much an answer bu a follow-up: I could not recreate the problem. So I can't reliably replicate the error message. It wasn't just a reboot. Because I did several of those.

I changed my PERL5LIB back to "C:\Documents and Settings\me\My Documents\..." ran some Perl fine, and just settled that that was the way it had to be.

Then I read ikegami's question in the comments and changed the Windows setting back to C:\Users\me\Documents\...\perl\lib and the Perl still ran fine--so did CPAN. I rebooted making sure that the environment variable was being set by the Junction names, and still perl and CPAN ran fine.

In the weeks since I've posted this question, I've never seen the problem again. And now here's the perl environment I run in:

C:\blahblahblah>perl -MSmart::Comments -MCPAN::SQLite -e "### @INC"

### @INC: [
###         'c:/Users/<me>/Documents/.../perl/lib',
###         'C:/strawberry/perl/site/lib',
###         'C:/strawberry/perl/vendor/lib',
###         'C:/strawberry/perl/lib',
###         '.'
###       ]

Thing is that in running the "old way", I might have reorganized my personal perl/lib to eliminate another problem.

But I think the answer is that it is likely Strawberry Perl has NO problems with NTFS Junctions...in the long run.