Front page | perl.perl5.porters |
Postings from April 2003
> 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. > And hence, I think perl should emulate them as it does fork(). Perl is not about making all operating systems alike. Every operating system that perl runs on has different limitations. > Anyways, you don't access a word document via C:\Some.lnk\file.doc, you access it by: > > a) opening up word, hitting the 'open menu' > b) clicking on the icons following file.doc down to its source. > c) clicking on the file.doc menu. > > How is this any different from accessing it via 'C:\some.lnk\file.doc' (except by making > it a bigger pain for the user)? Well, first of all, the code inside MS Word never sees the link. That's all handled by the "library" (generic term) that implements the Explorer type interface. By the time the source code inside MS Word sees it, it's C:\Blah\Blah\Blah\Blah\file.doc At no point _ever_ is C:\some.lnk\file.doc ever directly translated to C:\Blah\Blah\Blah\Blah\file.doc. Implementing fork()-like semantics is very different than creating something that doesn't currently exist anywhere. If you expect C:\some.lnk\file.doc to work, you should talk to Microsoft, maybe they'll put it in Windows 2005. If you want to write an add-on module that does this expensive and error-prone operation, go ahead. Or convince ActiveState that they need it. But it doesn't make any sense (IMHO) for this overspecialized feature to be part of the core. -RThread Previous | Thread Next