Chapter 20. IPC with send

20.1.1. Application Names

To verify that send works, run the rmt program (also available from the Perl/Tk distribution). This is a Tk remote controller that can send Perl commands to itself, although before rmt can send anything, it needs to know the address, or application name, of the target application.

Every Tk program is automatically assigned a default application name, usually the filename of the program, although the appname method can set the name programmatically. To avoid ambiguities, Tk insists that application names be unique and appends a number if needed, as shown in Figure 20-1.

Figure 20-1. A remote controller showing application names

To find your own application name, use the name method, and to see a list of active Tk programs, use interps:

my $name     = $mw->name;

my(@interps) = $mw->interps;

For the test, select the rmt application and type this statement in the window:

print STDOUT $MW, "\n";

Something like "MainWindow=HASH(0x822b090)" should print on your terminal, indicating that send is functioning normally. If the widget reference of the text widget you just typed into was $t, and you didn't like its background color, the following code changes it for you:

$t->configure(-background => 'azure');

Let's look under the hood and see how all this works.

20.1.2. Tk::Receive

As mentioned earlier, it's impossible to send to a Perl/Tk program unless its author has explicitly overridden the default receiver, Tk::Receive, and supplied her own. In this regard, Perl/Tk is a bit more secure than Tcl/Tk, since Tcl/Tk receives by default and requires programmers to disable that behavior manually. Perl/Tk goes even further and assumes that incoming data is tainted, so the program must run with taint checks on (-T command-line parameter). Tainted data is untrusted information coming from outside the program, so all received data, user input, command-line arguments in @ARGV, and most environment variables should be treated with suspicion. In fact, the HOME environment variable needs initialization just to create the MainWindow:

$ENV{HOME} = '/home/frog';

This prevents the program from aborting with this taint error:

tainted at /usr/local/lib/perl5/site_perl/5.005/i686-linux/Tk/MainWindow.pm line 55.
MainWindow->new( ) at ./rmt line 19

The Perl/Tk remote controller naturally (and potentially dangerously) eval s whatever it receives. Here's what it looks like:

sub Tk::Receive {

    # For security you must roll you own 'receive' command, run
    # with taint checks on and untaint the received data.

    my($mw, $cmd) = @_;

    $cmd =~ /(.*)/;
    $cmd = $1;
    eval $cmd; get_eval_status;

} # end Tk::Receive

The subroutine is called with two arguments: the application's MainWindow reference and a string containing whatever was sent, anywhere from a single line of text to an entire file. The string is then untainted and blindly eval ed.

For completeness, this is how send is invoked:

$t->send($appname, $cmd);

The Perl/Tk remote controller is designed to talk to other Perl/Tk applications, although there's no reason it can't connect to a Tcl/Tk application, as long as we remember to send Tcl/Tk commands (and vice versa, depending on which end is sending). Then again, a Tcl/Tk application returns Tcl results to the Perl sender, so it becomes unclear exactly how send should behave between languages. Indeed, this is another reason Perl/Tk left the receiving side of the interoperability equation undefined.

In this section, we used send in a pure Perl environment. The following sections investigate send in other applications. The first is pure Tcl, while the second is a hybrid Tcl-Perl mix.