Can xdotool be used from ssh?
Jeanne Petrangelo
Can I set the DISPLAY variable from the shell in the ssh session and then use xdotool to select the window and send keystrokes to it? That would let me use minicom without taking over the ssh session.
Is it possible to grab output from within that window, such as to verify the command succeeded?
I tried to install xdotool (as root, with sudo -s) on the host machine (red hat 4) and it says it can't find ldconfig. It seems there was no ldconfig in the path, so I added a path such that "which ldconfig" can find it, but it "make install" still says the ldconfig command is not found. What now?
Thanks,
Jeanne
Daniel Kahn Gillmor
> I need to automate a brief interaction with a minicom console, from a
> different linux machine ssh'ing in, completely from the command line. The
> minicom console is left open and can be accessed via VNC, if you don't mind
> using human interaction.
i hope it's OK to say this on the xdotool mailing list, but wouldn't you
rather just avoid X11 altogether for this task? xdotool might not be
the right tool for the job.
You've got some sort of serial connection to machine X, which you access
by ssh'ing into machine Y; right?
Why bother with X11 at all? Just invoke minicom from your SSH session
directly.
If the problem is that you want the minicom session to be running all
the time, even when you're not logged in, you could just run minicom
from GNU screen and detach before you log out so it stays in the
background -- still, no X11 session required.
And if you are actually talking to a serial console, you can even talk
to it directly from GNU screen, and cut out minicom itself. for
example, if you're using ttyS1 (COM2) at 115200 baud, you'd set up the
initial connection with:
ssh -t $remotehost screen /dev/ttyS1 115200
then when you're ready to disconnect and leave it running, do <Ctrl+a>
<d> to detach the screen session (which will in turn terminate the ssh
session).
When you're ready to reconnect, you'd do:
ssh -t $remotehost screen -x
If you've already thought this through and decided you must use X11 for
some reason, feel free to say so -- i certainly don't know the full
scope of what you need. But from what you've described so far, it seems
to me like getting xdotool involved would just create an extra layer of
problems you'd then have to solve.
Can you explain more about what you're trying to do?
Regards,
--dkg
Jeanne Petrangelo
On 10/06/2010 05:32 PM, Jeanne Petrangelo wrote:i hope it's OK to say this on the xdotool mailing list, but wouldn't you
> I need to automate a brief interaction with a minicom console, from a
> different linux machine ssh'ing in, completely from the command line. The
> minicom console is left open and can be accessed via VNC, if you don't mind
> using human interaction.
rather just avoid X11 altogether for this task? xdotool might not be
the right tool for the job.
You've got some sort of serial connection to machine X, which you access
by ssh'ing into machine Y; right?
Why bother with X11 at all? Just invoke minicom from your SSH session
directly.
That's a good question with an unusual answer. The host server keeps a VNC
session with minicom windows up and running, which people use. This is
inside some stringent corporate security measures.
X11 isn't a necessity, because I could kill those minicom sessions before
doing what I need, but the people would be happier if their minicom sessions
were not disrupted.
And if you are actually talking to a serial console, you can even talk
to it directly from GNU screen, and cut out minicom itself. for
example, if you're using ttyS1 (COM2) at 115200 baud, you'd set up the
initial connection with:
ssh -t $remotehost screen /dev/ttyS1 115200
then when you're ready to disconnect and leave it running, do <Ctrl+a>
<d> to detach the screen session (which will in turn terminate the ssh
session).
When you're ready to reconnect, you'd do:
ssh -t $remotehost screen -x
That's good information; thank you! I do have an option of bypassing
minicom and using a script to do it all, but I don't yet know enough of what
minicom does.
Can you explain more about what you're trying to do?
linux device under development. One serial port is used to transfer an
image and boot the device, and the other controls power so it can be
restarted if/when it hangs. The power console is easy enough to automate
with minicom's runscript, but the other uses menus which are navigated
by keyclicks, and I haven't figured out how to control that with runscript.
My first choice is to use runscript to automate minicom, because that
will be less complex than the alternatives. I cold either control the
existing minicom sessions, or kill them and then invoke minicom from
ssh. Alternately, I could use a script directly, but first I need to learn
what that script has to do exactly. For example, when a user selects
"[n]et-boot" in a minicom window, what command is actually sent to
the device? Writing such a script will take time and complexity.
Jeanne
Jeanne AT Petrangelo DOT org
you know
how I solved my problem.
First, since I hadn't seen minicom before, I had incorrectly assumed
that
the menus I needed to interact with were minicom's, but in fact they
were
generated by product firmware. That means even if the automation
bypassed
the minicom tool it would still need to deal with a console
application. So,
using xdotool would not have simplified anything for me. It also means
I
asked some confusing questions here, and for that I apologize.
I ended up using minicom's runscript expect-like scripting language to
navigate those menus, and I had to use "ssh -t -t" to connect to the
target's host computer and invoke minicom with that script.
Thanks again,
Jeanne
On Oct 7, 11:37 am, Jeanne Petrangelo <jea...@petrangelo.org> wrote:
> On Wed, Oct 6, 2010 at 8:56 PM, Daniel Kahn Gillmor
>