send - Execute a command in a different application
send ?options? app cmd ?arg arg ...?
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 containing 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 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.
- -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.
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.
If the send command is removed from an application (e.g.
with the command rename send {}) then the application
will 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.
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.
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 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, 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.
application, name, remote execution, security, send
Copyright © 1990-1994 The Regents of the University of California.
Copyright © 1994-1996 Sun Microsystems, Inc.
Copyright © 1995, 1996 Roger E. Critchlow Jr.