Front page | perl.perl5.porters |
Postings from May 2003
On Wed, Apr 30, 2003 at 10:50:59AM -0700, Edward Peschko wrote: > The point is that windows doesn't have symlinks - apparently without > the resource kit, and even then, only directory hard links. For > purposes of portablity across platforms it *should* have symlinks. So, your problem is that Windows is broken. No news here. > And hence, I think perl should emulate them as it does fork(). You're taking a huge logical leap from A to Q without really attempting to prove anything between B to P. It's not Perl's job to fix Windows, nor is it Perl's job to pretend everything is Unix. Windows programmers who use Perl don't expect symlinks, so no problems there. Unix programmers who use Perl on Windows expect Windows to be broken (e.g. no symlinks), so no problems there. Yes, it's a pain to port Perl scritps that assume symlinks exist, but that's a fact of life, and most people have grown to accept it. I don't see how fork() emulation is remotely relevant here, as a "precedent", an "example" or a "mandate" to make Perl lie to you and pretend that symlinks exist when they do not. The issue isn't that your problem isn't a valid one; it's that your proposed solution is invalid for many, many reasons. If you want support for Windows .lnk files, then please write a module for it. If you want to 'use lib "mylib.lnk";', there are ways around that problem, like preprocessing the .lnk file before it makes it into @INC or stuffing a coderef in @INC that uses your Windows .lnk processing module. But treating '*.lnk' as a symlink is a really bad idea. Remember, there's _ALWAYS_ more than one way to do it. While your proposed solution would help *you* in *your* *one* *specific* instance, it's not a good behavior for Perl in general. Try another idea instead. Z.Thread Previous | Thread Next