Welcome to the list.
TL;DR - it would help to know a bit more about the actual problem you
are trying to solve so we can give you a really good answer.
Below is my "AutoKey" answer, but having written it, I'm thinking that
there might be a better "Linux" answer (unless you have to type into a
gui app).
We'd have to know a bit more about what MYMCSERVER does and what its
interface options are to give you a really good answer.
Linux answer (if your target doesn't have to be a gui interface):
If your target program will only run commands from your queue (which is
essentially what you are creating), then you may just want to use a
named pipe as input to that program. You can do that in straight bash or
the shell of your choice. No AutoKey needed at all. If what you need is
simple enough, you might even be able to use a regular pipe for input.
I haven't done much with named pipes, but you use mkfifo to create one
and then redirect the input of your application to read from the named
pipe instead of from the terminal. Your program should happily keep
running and waiting for the next input until you close the named pipe or
close your application. Any other piece (or pieces) of code can write to
that named pipe and your application will receive the input. This can
all really happen in the background if your target application will
allow it.
To get it all started, you just run your script in the background by
ending the command with a " &". You can have that start from a terminal
or have it be auto started by your system or desktop. There are a bunch
of ways to do that depending on exactly what you need.
If it is run from a terminal window which you may want to close, then
you can start your command with "nohup " which will assure that your
program won't be terminated when the terminal window it was started from
is closed.
If you have the latest, greatest Windows 10 update, it includes a Linux
shell where you can test all of this out - using a dummy program to
receive the commands.
AutoKey answer:
I haven't coded enough Python to know for sure, but your code looks
essentially correct.
But, since there is no trigger (from the keyboard or mouse - you would
have to add an artificial one to get it started), this is more of a
daemon application. In this case you would probably want to use the
AutoKey scripting API built into a normal Python script run outside of
AutoKey itself. (I think AutoKey would still need to be running.)
As it is coded, your script is an intentional infinite loop. I would not
bet on AutoKey itself being happy with that. I don't think it would ever
run anything else. I don't know the code base, but I would guess that it
wants to do one macro to completion before it would look for another
trigger phrase.
In the script itself, you can just issue a keyboard.send_keys("<enter>")
after sending your command string (or you can just add a newline '\n' to
the end of each command line before sending it). Keep in mind that on
Linux, a newline is one character, not two like it is on Windows.
I haven't done this sort of thing before, so I may be wrong, but my
impression is that AutoKey only sends characters to the active window -
which you can modify within the macro/code body - but that means that
the window would pop up before it receives the input, so that's not as
elegant as being able to send a message to the receiving program's API
and have everything stay as it was on the screen. But, presumably, the
reason you want to do this is that the program doesn't have such an API.
I haven't done that yet, but other people on the list have.
With either of these approaches, you may have to add some delays between
commands because an app that expects human input may not be able to keep
up with an almost instant automated input stream.
Joe
> --
> You received this message because you are subscribed to the Google
> Groups "autokey-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to
autokey-user...@googlegroups.com
> <mailto:
autokey-user...@googlegroups.com>.
> For more options, visit
https://groups.google.com/d/optout.