Re: spurious deaths in script execution due to read-only Config?
Hi. U can't do that because Perl must autovivify $Config{bar} in order to
have a value to put into $_. HTH.
At 08:54 PM 2/21/2011 +0100, Christian Walde wrote:
use Config;
# print 1 if $Config{foo}; # enabling this removes the crash
grep { $_ } $Config{bar}; # this crashes
These two lines on their own will cause ActivePerl of any version to exit
with the error message above. I'm not sure what exactly causes this or
whether i should send this to the p5p mailing list, but i figured here is
better for a start.
--
REMEMBER THE WORLD TRADE CENTER ---= WTC 911 =--
...ne cede malis
0100
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: spurious deaths in script execution due to read-only Config?
On Tue, 22 Feb 2011 13:46:55 +0100, Chris Wagner wagn...@plebeian.com wrote:
At 08:54 PM 2/21/2011 +0100, Christian Walde wrote:
use Config;
# print 1 if $Config{foo}; # enabling this removes the crash
grep { $_ } $Config{bar}; # this crashes
These two lines on their own will cause ActivePerl of any version to exit
with the error message above.
Hi. U can't do that because Perl must autovivify $Config{bar} in order to
have a value to put into $_. HTH.
Good guess, that's almost what happens. The problem happens a bit deeper in the
guts and is actually caused by Exporter.pm, where it tries to do local $_ and
by doing so triggers autovivification. (grep/map only do an aliasing of %Config
to $_, which is fine.)
I remembered this morning that there is a bug tracker for ActivePerl, started
to write up an error report and in doing so ended up formulating a possible for
for ActiveState: http://bugs.activestate.com/show_bug.cgi?id=89447
--
With regards,
Christian Walde
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: NTFS hard file links
Jan, Your builtin link() is a godsend! If only I'd known years ago I could have saved a lot of heartache trying to kludge Win32::API::Prototype into working in my programs. I did a lot of testing of link() over this last weekend, and got mixed results. Here's my test environment: \FolderA\LinkTest.txt Original file \FolderA\FolderB\LnkdFil1.txt First hardlink \FolderA\LnkdFil2.txt Second hardlink I create a straight copy of an original text file in FolderA, naming it LinkTest.txt. I create a hardlink to LinkTest.txt in FolderB, naming it LnkdFil1.txt. I test that it is an actual hardlink by opening and editing both files; changes to either file show up in the other when opened. So far, so good. But then I create another hardlink to LinkTest.txt in FolderA (same folder as LinkTest.txt this time), naming it LnkdFil2.txt. Now I should have a total of three filesystem hardlinks pointing to the single original file on disk, right? I unlink the original LinkTest.txt, and that should leave me with two remaining links to the same file on disk (since NTFS uses link counting, in much the same way as Perl employs reference counting). But testing demonstrates that I now have two separate files on disk -- each with a single link to it -- rather than two links to the same file. Do I have a bad understanding of the concepts, of how hardlinks are supposed to work? Am I doing something wrong, or in the wrong order? Or is there some deficiency in the implementation of Windows hardlinks through link()? One final question: since symlinks were enabled in NTFS.sys v6.0 (Windows Vista) and above, is there any possibility that the builtin symlink() function can be made to silently Do the Right Thing on recent versions of Windows? Windows requires explicit declaration if the symlink is to a directory, but I think that it could be implemented in Perl in such a way that Perl simply handles the symlink() call correctly -- no matter what arguments it is handed. Here is the /? for the most recent MKLINK command: MKLINK [[/D] | [/H] | [/J]] Link Target /D Creates a directory symbolic link. Default is a file symbolic link. /H Creates a hard link instead of a symbolic link. /J Creates a Directory Junction. Linkspecifies the new symbolic link name. Target specifies the path (relative or absolute) that the new link refers to. At this point, we should have all of the linking functionality in Windows that is available in *nix. Thank you, -Brian Quoting Jan Dubois j...@activestate.com: On Thu, 17 Feb 2011, Brian H. Oak wrote: For years now I've been using Win32::API::Prototype to access kernel32.dll and set up CreateHardLink() for use in a program. But something in the upgrade from 32-bit 5.10 to 64-bit 5.12 is incompatible with Win32::API::Prototype. Now I'm looking for an alternative method for creating hard links that works with 64-bit 5.12. Does anyone know of a compatible module that provides this functionality? Have you tried the link() builtin function? It should call the CreateHardLink() function internally. I think I implemented it back in the 5.004 or 5.005 days, with an compatibility hack for Windows NT4, which doesn't have CreateHardLink(). Anyways, please let me know if it doesn't work; it is supposed to do the right thing automatically. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Pulling PERL Exectuable x86 vs x64
Is there a simple way to determine what flavor of PERL is running from within a program, specifically one that is wrapped within PERLAPP? In other words, I need to determine if the PERL is 32-bit or 64-bit, to determine if it is running in WoW64 or not. I realize it is easy to determine the flavor of the OS, but this is not that question. Regards, Michael Cohen___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Pulling PERL Exectuable x86 vs x64
Load Config.pm and look at $Config{ptrsize}. It is either 4 or 8, telling you
that you are running 32-bit or 64-bit Perl.
Cheers,
-Jan
From: perl-win32-users-boun...@listserv.activestate.com
[mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of
Michael Cohen
Sent: Tuesday, February 22, 2011 1:06 PM
To: perl-win32-users@listserv.ActiveState.com
Subject: Pulling PERL Exectuable x86 vs x64
Is there a simple way to determine what flavor of PERL is running from within a
program, specifically one that is wrapped within
PERLAPP? In other words, I need to determine if the PERL is 32-bit or 64-bit,
to determine if it is running in WoW64 or not. I
realize it is easy to determine the flavor of the OS, but this is not that
question.
Regards,
Michael Cohen
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Pulling PERL Exectuable x86 vs x64
Jan,
Thanks a lot!! That did the trick.
Regards,
Michael Cohen
From: Jan Dubois j...@activestate.com
To: Michael Cohen/Raleigh/IBM@IBMUS,
perl-win32-users@listserv.ActiveState.com
Date: 02/22/2011 04:18 PM
Subject:RE: Pulling PERL Exectuable x86 vs x64
Load Config.pm and look at $Config{ptrsize}. It is either 4 or 8, telling
you that you are running 32-bit or 64-bit Perl.
Cheers,
-Jan
From: perl-win32-users-boun...@listserv.activestate.com [
mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of
Michael Cohen
Sent: Tuesday, February 22, 2011 1:06 PM
To: perl-win32-users@listserv.ActiveState.com
Subject: Pulling PERL Exectuable x86 vs x64
Is there a simple way to determine what flavor of PERL is running from
within a program, specifically one that is wrapped within PERLAPP? In
other words, I need to determine if the PERL is 32-bit or 64-bit, to
determine if it is running in WoW64 or not. I realize it is easy to
determine the flavor of the OS, but this is not that question.
Regards,
Michael Cohen
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: NTFS hard file links
On Tue, 22 Feb 2011, Brian H. Oak wrote: Your builtin link() is a godsend! If only I'd known years ago I could have saved a lot of heartache trying to kludge Win32::API::Prototype into working in my programs. Looks like I added support for it in 1999: http://perl5.git.perl.org/perl.git/commitdiff/6b980173 I did a lot of testing of link() over this last weekend, and got mixed results. Here's my test environment: \FolderA\LinkTest.txt Original file \FolderA\FolderB\LnkdFil1.txt First hardlink \FolderA\LnkdFil2.txt Second hardlink I create a straight copy of an original text file in FolderA, naming it LinkTest.txt. I create a hardlink to LinkTest.txt in FolderB, naming it LnkdFil1.txt. I test that it is an actual hardlink by opening and editing both files; changes to either file show up in the other when opened. So far, so good. But then I create another hardlink to LinkTest.txt in FolderA (same folder as LinkTest.txt this time), naming it LnkdFil2.txt. Now I should have a total of three filesystem hardlinks pointing to the single original file on disk, right? Yes I unlink the original LinkTest.txt, and that should leave me with two remaining links to the same file on disk (since NTFS uses link counting, in much the same way as Perl employs reference counting). But testing demonstrates that I now have two separate files on disk -- each with a single link to it -- rather than two links to the same file. I cannot reproduce this. How did you check for it? Here is a crude script that works for me: #!perl use strict; use warnings; my $tmp = C:\\tmp; system(rd/s/q $tmp\\lntest); system(del $tmp\\lntest.txt $tmp\\link.txt); system(echo foo $tmp\\lntest.txt); mkdir($tmp\\lntest) or die; link($tmp\\lntest.txt, $tmp\\lntest\\link.txt) or die; link($tmp\\lntest\\link.txt, $tmp\\link.txt) or die; system(echo bar $tmp\\lntest.txt); system(type $tmp\\link.txt); unlink($tmp\\lntest.txt) or die; system(echo baz $tmp\\lntest\\link.txt); system(type $tmp\\link.txt); __END__ c:\tmpperl lntest.pl foo bar foo bar baz So *after* I deleted C:\tmp\lntest.txt I appened to C:\tmp\lntest\link.txt and the appended text shows up in the C:\tmp\link.txt link, proving that the remaining link has not been broken by the first unlink(). I suspect that you are doing some operation that is not updating a file, but deleting and re-creating it. This will always break hard links. Do I have a bad understanding of the concepts, of how hardlinks are supposed to work? Am I doing something wrong, or in the wrong order? Or is there some deficiency in the implementation of Windows hardlinks through link()? link() will just invoke CreateHardLinkW() under the covers, so you should see exactly the same effect with your Win32::API based implementation. One final question: since symlinks were enabled in NTFS.sys v6.0 (Windows Vista) and above, is there any possibility that the builtin symlink() function can be made to silently Do the Right Thing on recent versions of Windows? Yes, there is, but I'm not sure it can still be done in time for Perl 5.14. There is just one more 5.13.11 dev release planned for March, and then 5.14 should come out in April/May, and new features may no longer be allowed into the tree (besides I don't think I have time to do this right away anyways). Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: NTFS hard file links
Quoting Jan Dubois j...@activestate.com: I suspect that you are doing some operation that is not updating a file, but deleting and re-creating it. This will always break hard links. I went over my test methodology with a fine-tooth comb, and discovered that I had indeed messed up the order of operations. I was doing link-delete-link, when it should have been link-link-delete. PEBKAC strikes again. One thing I forgot to mention is that I ended up creating a function named safecopy(), because I wasn't happy with how the builtin copy() silently clobbers an existing copy to file -- which behavior link() very nicely does not exhibit. I was probably expending skull sweat on safecopy() when I overlooked my ordering problem. One final question: since symlinks were enabled in NTFS.sys v6.0 (Windows Vista) and above, is there any possibility that the builtin symlink() function can be made to silently Do the Right Thing on recent versions of Windows? Yes, there is, but I'm not sure it can still be done in time for Perl 5.14. There is just one more 5.13.11 dev release planned for March, and then 5.14 should come out in April/May, and new features may no longer be allowed into the tree (besides I don't think I have time to do this right away anyways). I'll keep a sharp eye out for Perl 5.42 :-) Thanks again, -Brian ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
