Let me start by saying I agree with Corion's notes entirely. You can't run a script on Machine A and have it magically perform its Perl code on Machine B. At best it could cause Machine B to launch a Perl script which is already present there.

It sounds like you want to solve a common sysadmin issue, where you need to collect remote log information into a central location.

Two approaches, amongst many, to do this:

1. You could write complementary Perl scripts; one on Machine A which directs the activities in some way, and one on Machine B which performs the activities thusly directed. This will require that you establish some mechanism which permits them to communicate with one another.
2. The script on Machine A could simply read the log files from Machine B directly. This solution is easier to implement but can cause potentially disastrous amounts of network traffic. WARNING: This approach does not scale well.

Good luck with the script(s) -- I think this is one of the more common uses of Perl, so you'll get loads of help if you get stuck, once you've written some code you can show.

As a final note, there's nothing wrong with asking "theory" questions, so long as it's clear you're still in the Perl world. I do it all the time here, and the answers have, without fail, always led me to a solution.

Update: Fixed typo "complimentary" to "complementary" as originally intended. The scripts will not be expected to say positive things about each other; rather, they will be expected to work together well and perform roughly reciprocal functions. :: facepalm ::