Now its works..thanks a lot.... --Mohit
On 6/6/07, Jan Dubois <[EMAIL PROTECTED]> wrote:
Kenneth Ölwing wrote: > Jan Dubois wrote: >> I'll fix PerlApp for PDK 7.1 to automatically strip the \\?\ prefix >> from $0 and PerlApp::exe() to make this workaround >>unnecessary. > > Thanks Jan - what do you think about the issue at the heart of the > problem? I.e. the reason to mangle $0 in the first place is that '-f' > won't work with a \\?\ path - but shouldn't that be considered a bug? > If you agree can you file that as a bug (merely asking nicely since I > gather you might be knowledgeable about the actual code involved...) > or should the OP do that? No, Perl cannot support the \\?\ prefix right now. This prefix works only with the "wide character" APIs, whereas Perl uses the ANSI APIs for almost all file operations [*]. Perl also uses fixed width buffers throughout the code that could not accommodate longer filenames. This _may_ all be improved eventually, but not until Perl 5.12 at the earliest. You'll see that I "fixed" this problem in core Perl almost 2 years ago: http://groups.google.com/group/perl.perl5.porters/msg/d194a6d4be42143f I believe that change was also prompted by IIS6 using the prefix to load additional libraries, which created a problem for Perl-ISAPI and PerlEx. Cheers, -Jan [*] I've added some support to Perl and the Win32 module to allow processing of files whose names cannot be represented in the system codepage. I'll write something about it when it is being released in ActivePerl 821 (it will be core Perl in 5.8.9 and 5.10 too). The idea is essentially to automatically turn Unicode names into 8.3 short filenames whenever they cannot be encoded in the system codepage. This will work for glob(), readdir(), etc.
_______________________________________________ ActivePerl mailing list [email protected] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
