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

perl v5.38.2                                       2024-04-01                                          send(3pm)