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';
[download]

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;
    }
}
[download]

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())) {
    ...
}
[download]

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.

use Win32::File qw(:DEFAULT SetAttributes GetAttributes);
[download]

#!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";
}
[download]

First, the functions, SetAttributes and GetAttributes, must be specifically requested:

use Win32::File qw(:DEFAULT SetAttributes GetAttributes);
[download]

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

GetAttributes()
[download]

Instead of this:

Win32::File::GetAttributes()
[download]

...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

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';
}
[download]

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))
    ...
}
[download]

  sub check_dir_is_writeable {
    -d $_ && -w $_ && -x $_
  }
[download]

  if(check_dir_is_writeable($dir)) {
    # yay!
  } else {
    # ohnoes!
  }
[download]

eval "use Win32::File";

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

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" );
    }
[download]