It depends on a few things...

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]

On the other hand, if you need to base some of your commands on information that splay is printing to its STDOUT, you'll need to look into the Expect module -- it's designed specifically for that kind of thing, and gives you the ability to handle some fairly intricate and varied interactions based on "dialogs" with a child process.

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...)