I agree with @slm that this is something of a borderline question. The truth is, Windows incorporates its own remote access protocols as your Unix system incorporates its own. Microsoft Powershell has matured a great deal since it was introduced with Vista, and it can do most if not all of the things you'd expect a shell script to do for you on your Windows system. For instance, according to technet:
The Windows PowerShell remoting features are supported by the WS-Management protocol and the Windows Remote Management (WinRM) service that implements WS-Management in Windows. Computers running Windows 7 and later include WinRM 2.0 or later. On computers running earlier versions of Windows, you need to install WinRM 2.0 or later as appropriate and if supported. Currently, remoting is supported on Windows Vista with Service Pack 1 or later, Windows 7, Windows Server 2008, and Windows Server 2008 Release 2.
Of course making use of this from a Linux client presents some problems, but I expect a virtual machine would solve most of them, or even just a
ssh proxy. Contributing 5 minutes and the use of a search engine to my mild curiosity and I now know of the Pash project, though I will make no claims on its usefulness.
In the course of once again entertaining that mild-curiosity I revisited the
Pash sourceforge page and browsed just a little more. While doing so, I noticed that the associated RECOMMENDED PROJECTS included not only the
winexe that @slm recommends, but another I'd never heard of called
win-bash. From the description:
bash ports for Windows (e.g. the
cygwin bash ), the
win-bash needs no special environment or DLLs. There is just one binary and that's it.
The goal of the
win-bash project is to finish the port to Windows and provide a fully-functional
bash.exe binary for Windows NT and derived systems.
win-bash can be used as an input shell, as well as an interpreter to run UN*X shell scripts.
What I find significant about the above regarding this question is its standalone nature. If it has no library or registry dependencies, a Windows executable can be remotely executed - for instance from a file share - without installation. So it is conceivable that you could remote into a machine using native Windows protocols (possibly also with or including
winexe ), run a
net use command to map a file share, execute your shell script via
win-bash, then unmap the share and terminate the connection without having to copy even a single file to the remote host.
I say it is conceivable, but does it work? I don't know, though I might just find out.
I like to keep a current win pe image on my system's EFI partition so it is available to
rEFInd (and bootable thanks to an
iPXE hack or two). So far I've only customized it to block the default Windows install starting and set it to open a
cmd prompt proxied by
cygwin seemed to me to be an awful lot of chore for little return, but now my previously mild curiosity is growing... I'll likely return with a report on my experience afters adding it to my pe image.
winexe, of which I had never heard before, though I am now interested. He also mentions
wmic as a tool you can use, and that is a tool which I have often used myself - it grants you pretty powerful access to the Registry backend using SQL-like syntax.
I do know that if you wish to execute
.cmd scripts based on specific rules there is the Windows Task Manager and Windows Group Policy, both of which, as I believe, you can influence at least to some degree via
Last I will say that porting code from one operating system to another is not done as often as we might like for a reason: it is problematic by its very nature. Different operating systems behave differently, if nothing else, at the least because they are different.
ssh for instance, at least in my experience, was incapable of handling Windows' graduated permissions and required either system level access or simply did not work, though
netcat seemed to accept the permissions level of the user account under which I ran it. Powershell, as I mentioned above, can be an extremely tedious tool if used for parsing strings, as you may be accustomed to do in a Unix environment, because it treats everything as an object in its own right. So good luck.