NAME
send - Execute a command in a different application
SYNOPSIS
send ?options? app cmd ?arg arg ...?
_________________________________________________________________
DESCRIPTION
This command arranges for cmd (and args) to be executed in
the application named by app. It returns the result or
error from that command execution. App may be the name of
any application whose main window is on the display con
taining the sender's main window; it need not be within
the same process. If no arg arguments are present, then
the command to be executed is contained entirely within
the cmd argument. If one or more args are present, they
are concatenated to form the command to be executed, just
as for the eval command.
If the initial arguments of the command 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 applica
tion; 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.
-displayof pathName
Specifies that the target application's main window
is on the display of the window given by pathName,
instead of the display containing the application's
main window.
-- 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 tk appname command.
DISABLING SENDS
If the send command is removed from an application (e.g.
not respond to incoming send requests anymore, nor will
it be able to issue outgoing requests. Communication can
be reenabled by invoking the tk appname command.
SECURITY
The send command is potentially a serious security loop
hole. On Unix, any application that can connect to your X
server can send scripts to your applications. These
incoming scripts can use Tcl to read and write your files
and invoke subprocesses under your name. Host-based
access control such as that provided by xhost is particu
larly insecure, since it allows anyone with an account on
particular hosts to connect to your server, and if dis
abled it allows anyone anywhere to connect to your server.
In order to provide at least a small amount of security,
Tk checks the access control being used by the server and
rejects incoming sends unless (a) xhost-style access con
trol 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. Under Windows, send is currently |
disabled. Most of the functionality is provided by the |
dde command instead.
KEYWORDS
application, dde, name, remote execution, security, send |
Man(1) output converted with
man2html