in reply to Getting VBA code to run a Perl script in a network drive

the start command (if you can execute system commands from vba) with the perl file as the parameter should work on a windows box. if the machine is constantly connected to the network with the same name then you can identify it. However the request initiator will need to send a request to a request handler on the target machine.. the request handler would then execute the program on its local machine. IO::Socket would be your best bet to get started in terms of setting up a requester/handler mechanism. However you will need to translate the network name to an IP address. CPAN might have a module that will do that. i.e \\HANDLER eq '192.168.1.105' Having the perl program held on the network drive isn't an issue.. the handler just has to know what drive letter it is mapped to on the handler. the requestor doesn't care.

/ramble off

Grygonos
  • Comment on Re: Getting VBA code to run a Perl script in a network drive

Replies are listed 'Best First'.
Re^2: Getting VBA code to run a Perl script in a network drive
by Win (Novice) on Dec 09, 2004 at 14:20 UTC
    Would it be suitable to have a Perl program running in the background that looks for submitted requests to the network drive, acting accordingly when it finds them? Can anyone point me to the best approach to doing this (if it is feasible)?
      Sure, you could do something like this on the machine you want the job processes to actually run on:
      use File::Slurp; chdir '/path/to/shared/directory/jobs/dropoff' or die $!; for (;;) { foreach my $job (read_dir(".")) { next unless $job =~ /\.pl$/; system "perl -w $job > $job.output"; rename $job, "$job.ran" or warn $!; } sleep 5; }
      You probably want to do something fancier with giving jobs unique names and so on, but that's the idea.

      Make sure the dropoff area has appropriate permissions.

      As for the dynamic IP thing, get your sysadmin to set up DNS properly so you can refer to the machine by name.

      If that's not possible, an easy fix would be to do whatever the windows equivalent of HEAD http://machine-you-control/here-i-am-`hostname` is in a DHCP client script, and then look in the logs on machine-you-control.