Python: connect to already opened console application - python

I have an interactive console application and I need to work with it using Python (send commands and receive output). The application is started by another one, I can't start it from Python script.
Is it possible to connect to already running console application and get access to its stdin/stdout?
Ideally the solution should work both in Windows and Unix, but just Windows version would also be helpful. Currently I am using the solution found here
http://code.activestate.com/recipes/440554/
but it doesn't allow connecting to existing process.
Thanks for any input,

Have you considered using sockets since they are straight forward for simple/streaming. They are also platform independent.
The most critical point is thread safety where having to pass IO streams between threads/processes tends to be hectic.
If on the other hand you use a socket, a lot can be communicated without adding too much complexity to how the processes work(coding an error prone RPC for instance).
try Documentation or
example

Related

How to detect of my python script is getting proxied/debugged

I have a client based application written in python. It is using some sensitive api's. A way to prevent people to find these would be to check for known debbuger processes running, but this can easily be tricked by renaming the process or runnning the script on a pc, getting debugged by an external device checking the traffic.
Would there be a way to detect if the internet connection is running trough a normal ip and not a proxy or the internet traffic is being watched?
I not looking for a specific pythonic way, just a general solution that I can convert into a python script later.

read stdout of a Linux process spawned by a wine application

I have a CLI application which is executed via Wine on Linux as it needs some closed source DLLs which are only available for Windows. However I also have another tool which is much easier to compile/run on Linux. That Linux application communicates via STDIN/STDOUT.
So I want to spawn a native Linux process from Wine, pass some data (ideally via stdin), wait for the process to complete and read its result (ideally via stdout). This is trivial if both processes would be run in the same OS environment (pure Linux/Posix/Windows) but more complicated in my case.
I can spawn a Linux process using popen but I can't get its stdout (always getting an empty string).
I understand that Wine itself won't/can't provide blocking process creation (probably this creates a lot of edge cases when trying to maintain Windows semantics) as detailed in Wine bug 18335, stackoverflow answer "Execute Shell Commands from Program running in WINE".
However the Wine process is still running under Linux so I think it should be possible to somehow tap into Linux's (= kernel) functionality and do a blocking read.
Does anyone have some pointers on how to launch a Linux process and get its stdout from Wine?
Any other ideas on how to do IPC without complicated server installs?
Theoretically I could use to file system and wait for a result file to appear or run a TCP/HTTP server for communication. Ideally the input is only accessible for the launched application without a server port which every application on the same host can access.
I read about "winelib" as a way to access native Unix functionality from "Windows" programs but I'm not sure I fully grasp how to use it and if it helps me (I can adapt the Wine program but as I mentioned earlier I need to access some closed source DLLs which I can not modify).
Edit: I just noticed the zugbruecke library which allows to communicate with a Windows DLL from (Unix) Python (via a custom wine+TCP connection from Python's multiprocesing). I can not use that as-is (my DLL library uses a lot of pointers so I have wrapped it via pybind11) and it would mean I have to rework my application a bit. However it might result in an elegant solution where the Windows bits are more isolated and I can have more Linux fun. :-)

Best practice for an infinite loop Python script that runs on Windows as a Service

I have a python script that reads data from an OPCDA server and then push it to InfluxDB.
So basically it connects to the OPCDA using the OpenOPC library and to InfluxDB using the InfluxDB Python client and then starts an infinite while loop that runs every 5 seconds to read and push data to the database.
I have installed the script as a Service using NSSM. What is the best practice to ensure that the script is running 24/7 ? How to avoid crashes ?
Should i daemonize the script ?
Thank you in advance,
Bnjroos
I suggest at least to add logging at the script level. You could also use custom Exit Codes from python so NSSM knows to report failure. Your failure would probably be when connecting to your services so, i.e. netowrk down or something so you could write custom exceptions for NSSM to restart. If it's running every 5 seconds you would probably know very soon.
Ensuring availability and avoiding crashes is about your code more than infrastructure, hence the above recommendations.
I believe using NSSM (for scheduling and such) is better than daemonizing, since you're basically adding functionality of NSSM in your script and potentially adding more code that may fail.

Using sys.stdin in select.select on Windows [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Can select() be used with files in Python under Windows?
On UNIX I am able to pass sys.stdin to select.select in Python. I am attempting to do this on Windows, but select.select in Python on Windows will not allow it.
To more accurately describe what I am doing see https://github.com/eldarion/gondor-client/blob/ccbbf9d4b61ecbc2f66f510b993eb5fba0d81c09/gondor/run.py.
The unix_run_poll function is what I am trying to accomplish on Windows. The basic idea is that I have a socket connection to a server which has hooked up streaming stdin, stdout, stderr to a process running remotely and I am interacting with it from the local client and making it appear as if the local client is running the process.
The win32_run_poll is my attempt at porting it to Windows and it does work, sort of. It is a little wonky and the approach, IMO, is very bad.
Does anyone have suggestions on how this can be improved? The dependency on win32api is less than ideal, but I am okay with keeping it.
On Windows select is only defined for sockets, and will not work for arbitrary file handles (windows has no concept of file descriptors). For more information about this issue, see the msdn documentation, it is also mentioned in the python documentation for the select module.
If you want to use polling for arbitary files, you should look into something that abstracts polling sockets and file handles. This might be the twisted reactor referred to in a comment to your post, or it might be a python binding to libuv, or some other event library of your choice.

running a python script on a remote computer

I have a python script and am wondering is there any way that I can ensure that the script run's continuously on a remote computer? Like for example, if the script crashes for whatever reason, is there a way to start it up automatically instead of having to remote desktop. Are there any other factors I have to be aware of? The script will be running on a window's machine.
Many ways - In the case of windows, even a simple looping batch file would probably do - just have it start the script in a loop (whenever it crashes it would return to the shell and be restarted).
Maybe you can use XMLRPC to call functions and pass data. Some time ago I did something like that you ask by using the SimpleXMLRPCServer and xmlrpc.client. You have examples of simple configurations in the docs.
Depends on what you mean by "crash". If it's just exceptions and stuff, you can catch everything and restart your process within itself. If it's more, then one possibility though is to run it as a daemon spawned from a separate python process that acts as a supervisor. I'd recommend supervisord but that's UNIX only. You can clone a subset of the functionality though.

Categories

Resources