1. Have your script pretend to be user interaction
2. Control the STDIN filehandle

First: would "splay" be running as a child process of the controlling perl script? (If it's being run independently from a separate shell, I think the idea of controlling it from a perl script won't make any sense. In order for the perl script to control the process by "talking" to splay's STDIN, splay has to be a child process launched by the perl script.

Second: does splay provide any feedback via its STDOUT, such that a later entry to its STDIN (the next command) would depend on what the feedback was? In other words, when you use splay in the "normal way", do the inputs you enter depend on the stuff it prints to the terminal between your entries?

If you are talking about controlling a child process where your commands don't depend on feedback, you can open the child process as an output file handle, like this:

open( my $splay, "|-", "splay @args" ) or die "Couldn't start splay: $
+!";

#  Now just print command line strings to the $splay file handle...

sleep 10;
print $splay "STOP\n";   # (just guessing what sort of command you wou
+ld send)
[download]

Update: Sorry, after reading the OP more carefully, I see you clearly said that "splay" is not being run as a child process of the perl script. I think there should be a way to create a "wrapper" script for starting "splay" (you could rename the actual splay executable to, say, "splay.real", and have the wrapper script named "splay").

The wrapper would provide some sort of IPC mechanism (named pipe, sockets or whatever -- see perlipc) so that some other script, being run independently, could talk to it and send commands that would be relayed to the "splay.real" child process. In this case, the wrapper script is running splay as a child process, using a pipeline file handle or Expect, as appropriate, to control it based on the inputs it gets from a connecting perl script.

But here's the catch: if a user is launching splay before the control perl script starts up, is the user expecting to send manual commands to splay via its STDIN? I don't think you can have it both ways -- either its controlled interactively by a user typing to the tty (normal stdin operation), or it's getting stdin from a parent process.

(Last update: on second thought, the wrapper script could be written in a clever way that would support both "normal" tty input and "intrusive" input from an independent client process. It simply has to poll both sources for as long as the splay.real child is running. Could be an interesting app on a multi-user system, if two or more people have permission to control the same process simultaneously...)

The last time I tried it, this was as far as I got...... a non-working snippet

#!/usr/bin/perl
use warnings;
use strict;
use X11::SendEvent;
use X11::WMCtrl;
use Data::Dumper;

my $wmctrl = X11::WMCtrl->new;
my @windows = $wmctrl->get_windows;
print Dumper([\@windows]),"\n";

$wmctrl->activate('foo');

$|++;
my $win = X11::SendEvent->new( win => [ 'foo' ], debug => 1 );


for(1..100){
$win->SendString( "testing", [ "Return" ] );
$win->SendString( "user", [ "Return" ], "joe", [ "9/1" ] );
$win->SendKeycode( 119 );
$win->SendString( "zentara", [ "Return" ], [ "Return" ] );
}

<>;
[download]