The problem you have isn't technical. It's political. The remote users don't have login access. There's a reason why. Whatever solution you will end up, it has to follow those constraints.

You need to talk to the people in charge of the machine, express your wishes, and work out how to solve that issue. That's way better than asking for a skript kiddie solution on Perlmonks.

By far the simplest way to allow remote users to run processes on your server, would be to give them ids on the server.

These IDs can be locked down tight so that they can only see whatever you chose to let them see; and run whatever you choose to let them run.

If they are other windows users on the same LAN/WAN then you only need add their domain IDs to an appropriate group on your server and the job is pretty much done. After all, this is what multi-user OSs are all about. If you don't know how to go about setting up an appropriately locked-down group, consider talking to your local systems administrator.

Alternatively, if the users are getting to your server via the internet; or from machines running other OSs, then perhaps setting up a simple webserver which authenticates the users, and then presents them with a menu of tasks they can run would be your best option.

Please don't be offended, but when you use phrases like "how do I run the socket", it indicates a lack of knowledge on your behalf that means that you trying to replicate even a small part of existing OS or webserver functionality yourself, in Perl, really isn't a good idea.

Yes, I know nothing about Sockets. I created a simple socket from examples that I found. It works fine saying hello world. I don’t deal with internet programming, I deal with data, data retention, data manipulation, data collection etc.. The technicians that spend hours transferring the large data files from the secured/isolated remote testing network to the workstation know nothing about logging on remotely. Their managers wont let them spend the time logging on remotely (I gave them simple instruction), it is very political. They have read/write access to the shared link to where they put the data on the workstation. When they were done getting the data to the shared workstation I wanted to make a batch file or a perl script that they could simply double click to run the conversion. They know when the data is available and sometimes the data is needed to be converted asap. I do have scheduled times for data conversion but they sometimes need the data at strange time. Sorry to waist your time.

Sorry to waist your time.

You didn't waste my time. I was attempting to avoid wasting yours.

Programming, setting up, and maintaining, all the code, logistics and required security that sit behind your desired: "I wanted to make a batch file or a perl script that they could simply double click to run the conversion. " is a very involved process that would require you to learn substantially more about programming that you currently know.

And the main point is, what you want is actually quite easy to setup, quickly & securely, using the existing facilities of your OS. But programming it in Perl will require considerable effort.

If you are considering doing it in Perl in order to bypass some political barriers, then you should really think twice 10 times before going ahead.

Because, if by doing this, you are crossing some "political" boundaries, then it could very well end up being detrimental to your source of income and career. Especially if you get the hardest aspect of the task--security--wrong.

If you really insist on going ahead, then the simplest mechanism would be to create two directories below the current shared directory--say \\yourWorkstation\sharedspace\IN & \\yourWorkstation\sharedspace\OUT--and then you run--once at the beginning of each day or week--a simply script that monitors the IN directory, when it sees a file appear there, it runs the conversion process and writes the results to the OUT directory.

Now all your users have to do is upload the files to the IN directory, and then check the OUT directory to see when the converted files are ready.

But even this is not entirely trivial as your program will need to to not only detect when the files appear in the IN directory, but also wait until their upload is complete before starting to process them.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

If I understand your question, you basically would like to Telnet to the Windows box and run some scripts - which would execute on the remote Windows box. This is like the *nix paradigm

Unfortunately, Windows doesn't work like that. There is a Telnet service for Windows - not sure if it's installed by default or only available on Windows Server flavors, but that would require each user to have login credentials (you say they don't have remote log on access).

VNC or Windows equivalent - Terminal Services - is an option, but again, remote log on access is required for TS and VNC would require users knowing a shared password for direct remote console access.

Finally, there is psexec.exe from SysInternals. This also requires remote credentials.

The socket path you're going down seems reasonable, but without any authentication/authorization, couldn't anyone connect and force your scripts to run? That doesn't seem so secure.

Do you have any code done yet? Can you post something so we could be more help?

One alternative is to run your script periodically. You probably need to slightly adjust your script, so it knows whether there is any new data to be processed.

On the other hand, it is a fine idea to use a socket to talk. the coding is minimum.

Other possibilities would be ... Windows remote access ... setting up a web-server-type program ... using a shared file that someone on another computer can write into ... using named pipes with a little slave-program that’s always running, listening to it.

Regardless of those “possibilities,” you can be almost 100% certain that what you are considering doing, has already been done before.   You shouldn’t even have to use Perl.   Do some “Googling” to look at the existing body of work that should be available.

For example, Googling “Windows remote execution” talks about things like rexec, rsh, and even one article (on page one) titled, “DoIt:   Yet Another Remote-Execution Daemon for Windows.”   I have not examined any of these programs; nor do I intend to.

The fastest way to do anything, is to find a way not to have to do it at all.   To reduce your problem into a problem that is already-solved.   To a program that has already been written (even if you pay for it).

If it's as political as you indicate then you need to extricate yourself from the situation!! This is something your management should be working out with their management. And if it is your management that says this has to be done then you need to ask what the ramifications of doing something like this are instead of diving into a technical solution. And then you need to make sure your management understands the repercussions and make sure you get that in writing or in an email (i.e. that your management understands what they are getting into).

Good luck and be careful!

Provide .bat files (on the shared link perhaps) which use the schtasks Windows command to run the tasks. Users can just double-click the bat files to run your scripts.

If needed, you could have the bat files accept paramters and write them out to .ini files on the shared link which could then be read by the scripts. You'd have to consider problems such as two users running the same bat file at once, but it's doable.

Problem solved, no security issues.

I would even go as far as to hint towards Powershell if politics is an issue, many Windows admins are more comfortable with using that cra^H^H^Hlanguage because they (incorrectly ofcourse) believe the code is easier to read than Perl.