NAME

       Tk::send - Execute a command in a different application

SYNOPSIS

           $result = $widget->send(?options,?app=>cmd?arg arg ...?)

DESCRIPTION

       This method arranges for cmd (and args) to be 'sent' to the application named by app.  It
       returns the result or an error (hence above should probably be 'wrapped' in eval{} and $@
       tested).  App may be the name of any application whose main window is on the display
       containing the sender's main window;  it need not be within the same process.  If no arg
       arguments are present, then the string to be sent is contained entirely within the cmd
       argument.  If one or more args are present, they are concatenated separated by white space
       to form the string to be sent.

       If the initial arguments of the call begin with ``-'' they are treated as options.  The
       following options are currently defined:

       -async
           Requests asynchronous invocation.  In this case the send command will complete
           immediately without waiting for cmd to complete in the target application;  no result
           will be available and errors in the sent command will be ignored.  If the target
           application is in the same process as the sending application then the -async option
           is ignored.

       --  Serves no purpose except to terminate the list of options.  This option is needed only
           if app could contain a leading ``-'' character.

APPLICATION NAMES

       The name of an application is set initially from the name of the program or script that
       created the application.  You can query and change the name of an application with the
       appname method.

WHAT IS A SEND

       The send mechanism was designed to allow Tcl/Tk applications to send Tcl Scripts to each
       other. This does not map very well onto perl/Tk.  Perl/Tk "sends" a string to app, what
       happens as a result of this depends on the receiving application. If the other application
       is a Tcl/Tk4.*  application it will be treated as a Tcl Script. If the "other" application
       is perl/Tk application (including sends to self) then the string is passed as an argument
       to a method call of the following form:

       $mainwindow->Receive(string);

       There is a default (AutoLoaded) Tk::Receive which returns an error to the sending
       application. A particular application may define its own Receive method in any class in
       MainWindow's inheritance tree to do whatever it sees fit. For example it could eval the
       string, possibly in a Safe "compartment".

       If a Tcl/Tk application "sends" anything to a perl/Tk application then the perl/Tk
       application would have to attempt to interpret the incoming string as a Tcl Script. Simple
       cases are should not be too hard to emulate (split on white space and treat first element
       as "command" and other elements as arguments).

SECURITY

       The send command is potentially a serious security loophole, since any application that
       can connect to your X server can send scripts to your applications. Hence the default
       behaviour outlined above.  (With the availability of Safe it may make sense to relax
       default behaviour a little.)

       Unmonitored eval'ing of these incoming "scripts" can cause perl to read and write files
       and invoke subprocesses under your name.  Host-based access control such as that provided
       by xhost is particularly insecure, since it allows anyone with an account on particular
       hosts to connect to your server, and if disabled it allows anyone anywhere to connect to
       your server.  In order to provide at least a small amount of security, core Tk checks the
       access control being used by the server and rejects incoming sends unless (a) xhost-style
       access control is enabled (i.e. only certain hosts can establish connections) and (b) the
       list of enabled hosts is empty.  This means that applications cannot connect to your
       server unless they use some other form of authorization such as that provide by xauth.

SEE ALSO

       "eval" in perlfunc, Safe, system's administrator/corporate security guidelines etc.

KEYWORDS

       application, name, remote execution, security, send