Execute a command in a different application


(send ?options? app cmd ?arg arg ...?)


This procedure arranges for cmd (and args) to be executed in the application named by app. It returns the result (converted to a string) that procedure 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 procedure to be executed is contained entirely within the cmd argument. If one or more args are present, they are concatenated to form the procedure to be executed, just as for the eval procedure.

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

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

:displayof widget-name
Specifies that the target application's main window is on the display of the window given by widget-name, 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 procedure.


The send procedure can be removed from an application by calling the inhibit-send procedure. If the send procedure is removed 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 procedure.


The send procedure 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 STk 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.



Back to the STk main page