send(3)
NAME
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 pro
cess. 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 sepa
rated 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 cur
rently 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 com
mand 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 con
tain 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 applica
tions 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 applica
tion 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 loop
hole, 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 pro
vided 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 con
trol 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 applica
tions cannot connect to your server unless they use some
other form of authorization such as that provide by xauth.
SEE ALSO
Perl's eval perl's Safe Module system's administrator/cor
porate security guidelines etc.
KEYWORDS
- application, name, remote execution, security, send