Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

including modules during runtime and dealing with OS specific (constants) code block

by periferral (Novice)
on Aug 01, 2011 at 21:15 UTC ( #917920=perlquestion: print w/ replies, xml ) Need Help??
periferral has asked for the wisdom of the Perl Monks concerning the following question:

After reading the forums, I figured out how to include runtime modules based on specific operating systems. Right now I have something like this
my $OS = $^O; if ($OS =~ m/win32/i) { eval "use Win32::File"; eval "use Win32::FileSecurity"; } if ($OS =~ /darwin/) { do something else } if ($OS =~ m/win32/i) { my $attrib; Win32::File::GetAttributes($http_rec_localdir, $attrib); if ($attrib & (Win32::File::SYSTEM | Win32::File::HIDDEN)) { &error_dialog( "Destination Directory", "Destination directory is not writable." ); return; } }
The code compiles fine on windows however on Mac, it fails since Win32::File was not included. The message for failure

"Bareword 'Win32::File::SYSTEM' not allowed while 'strict subs' in use at ...."

Can someone suggest a solution. Much appreciated

Comment on including modules during runtime and dealing with OS specific (constants) code block
Download Code
Re: including modules during runtime and dealing with OS specific (constants) code block
by tj_thompson (Scribe) on Aug 01, 2011 at 22:54 UTC

    I'm uncertain how to get by your problem without turning off strict/warnings for that issue locally in your scope. Obviously that constant is defined in the Win32 module that's not being loaded on the mac. You can get around the issue like so:

    if ($OS =~ m/win32/i) { my $attrib; Win32::File::GetAttributes($http_rec_localdir, $attrib); no strict qw(subs); no warnings qw(bareword); if ($attrib & (Win32::File::SYSTEM | Win32::File::HIDDEN)) { &error_dialog( "Destination Directory", "Destination directory is not writable." ); return; } }

    This will allow the code to run. Be careful with this kind of approach as it can lead to silent failures. You have a tight simple scope here, so it should have minimal impact.

    Careful turning off strict or warnings anywhere in your code and make very certain those cases are tightly scoped. If you can make the code run without doing so, that's probably the right thing to do. Once in a while you bump into those situations that the capability was created for though.

      I'm uncertain how to get by your problem without turning off strict/warnings for that issue locally in your scope.

      In general, make barewords that would otherwise be function calls look to the parser like function calls:

      if ($attrib & (Win32::File::SYSTEM() | Win32::File::HIDDEN())) { ... }

      That's untested. You might have to use the prefix & instead.

        Haven't tested it on Windows to see if the code block works but the code seems to compile and run on Mac for now. Thanks.
Re: including modules during runtime and dealing with OS specific (constants) code block
by Khen1950fx (Canon) on Aug 02, 2011 at 04:28 UTC
    First, the functions, SetAttributes and GetAttributes, must be specifically requested:
    use Win32::File qw(:DEFAULT SetAttributes GetAttributes);
    Second, since you're using Win32::File, it doesn't do any good to try darwin. I eliminated darwin, and I deleted the eval. There was also a problem with &error_dialog being undefined, so I deleted that. Here's what I have so far:
    #!perl BEGIN { $| = 1; $^W = 1; } use strict; use warnings; use Win32::File qw( :DEFAULT SetAttributes GetAttributes ); my $name = '/root/Desktop/foo.txt'; my $attr = 0; Win32::File::SetAttributes( $name, $attr ); Win32::File::GetAttributes( $name, $attr ); if ( $attr & SYSTEM ) { print "$name has SYSTEM set.\n"; } if ( $attr & HIDDEN ) { print "$name is hidden.\n"; }
      First, the functions, SetAttributes and GetAttributes, must be specifically requested:
      use Win32::File qw(:DEFAULT SetAttributes GetAttributes);

      That would not actually make any difference here. The only difference it would make is allowing this syntax:

      GetAttributes()

      Instead of this:

      Win32::File::GetAttributes()

      ...which is not being attempted here. That specification just tells import() what to bring into the current package namespace from the module.

      The issue in play here is the 'eval', which gives the compiler no idea what will be available at runtime. So it fails at compile time. In your 'fixed' example, it's working not because of your added imports, its working because you removed the 'eval'.

      --Dave

Re: including modules during runtime and dealing with OS specific (constants) code block
by cdarke (Prior) on Aug 02, 2011 at 07:34 UTC
    The Win32 issues discussed above not withstanding, a better way of conditonally including modules is to use the if pragma. Here is a working fragment, you should be able to modify it for the APIs you need, and for Mac:
    use if ($^O eq 'MSWin32'), 'Win32::Process'; use if ($^O ne 'MSWin32'), 'POSIX'; use if ($^O ne 'MSWin32'), 'POSIX' => ':sys_wait_h'; # Hack to allow compilation under UNIX # (NORMAL_PRIORITY_CLASS is Win32 only) use if ($^O ne 'MSWin32'), 'constant' => 'NORMAL_PRIORITY_CLASS';
Re: including modules during runtime and dealing with OS specific (constants) code block
by DrHyde (Prior) on Aug 02, 2011 at 10:56 UTC

    In general, you're better off using Devel::CheckOS instead of looking directly at $^O.

    Second, I recommend putting all your platform-specific code into platform-specific modules. So, for example ...

    use Devel::CheckOS qw(os_is); if(os_is('MSWin32')) { eval 'use MyApplication::Platform::Win32'; } elsif(os_is('MacOSX')) { eval 'use MyApplication::Platform::MacOSX'; } else { warn "not MSWin32 or MacOSX, falling back to defaults\n"; eval 'use MyApplication::Platform::Default'; }
    Your MyApplication::Platform::* modules should then export the same set of subroutines that wrap up the platform-spceific bits, so that the core of your application is exactly the same no matter what platform. For example, they could all export a subroutine check_dir_is_writeable, whose Windows implementation would look like:
    use Win32::File; use Win32::FileSecurity; sub check_dir_is_writeable { my $http_rec_localdir = shift; my $attrib; Win32::File::GetAttributes($http_rec_localdir, $attrib); if ($attrib & (Win32::File::SYSTEM | Win32::File::HIDDEN)) ... }
    and whose Mac OS X implementation is:
    sub check_dir_is_writeable { -d $_ && -w $_ && -x $_ }
    Your application then can just do this to have it work on either platform:
    if(check_dir_is_writeable($dir)) { # yay! } else { # ohnoes! }
Re: including modules during runtime and dealing with OS specific (constants) code block
by armstd (Friar) on Aug 02, 2011 at 17:14 UTC
    eval "use Win32::File";

    You can just use 'require' instead if you just want it to happen at runtime.

    require Win32::File;

    I even go as far as using 'require' more than I use 'use' these days for modules it seems. You lose the questionable benefits of import(), but you're not taking advantage of import() in this example anyway. As chromatic already pointed out, you'll want to avoid barewords referring to code that hasn't been compiled yet, addressing them as functions by appending '()' will work fine. No need for the '&'.

    In my experience, dynamically compiling during runtime is great, especially when loading a large number of modules over an NFS mount. Only loading what's needed as its needed will improve response time, reducing the initial compilation time. But compilation errors in the middle of execution can be bad, and that's why you really want the 'eval'. Not just to make use work at runtime, but to make sure runtime compilation errors are caught and handled in a user-friendly way.

    This is like what I do in my Abstract Factories:

    if( ! eval "require ${package}" ) ) { throw E_BadSubClass( "package '${package}' not found or failed + to compile.\n" . $@ . "\n" ); }

    --Dave

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://917920]
Approved by Corion
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (10)
As of 2014-07-29 20:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (228 votes), past polls