The send Command The send command invokes a Tcl command in another application. The general form of the command is: send options interp arg ?arg...? The send command behaves like eval; if you give it extra arguments, it concatenates them to form a single command. If your argument structure is important, use list to build the command. Table 40-1 lists the options to send: Table 40-1. Options to the send command.| -async | Does not wait for the remote command to complete. | | -displayof window | Sends to the application on the same display as window. | | -- | Delimits options from the interp argument. Useful if the interp begins with a dash. |
The interp argument is the name of the other application. An application defines its own name when it creates its main window. The wish shell uses as its name the last component of the file name of the script. For example, when wish interprets /usr/local/bin/exmh, it sets its application name to exmh. However, if another instance of the exmh application is already running, wish chooses the name exmh #2, and so on. If wish is not executing from a file, its name is just wish. You may have noticed wish #2 or wish #3 in your window title bars, and this reflects the fact that multiple wish applications are running on your display. If you use Tk 3.6 or earlier and your application crashes, it can forget to unregister its name. The tkinspect program has a facility to clean up these old registrations. A script can find out its own name, so you can pass names around or put them into files in order to set up communications. The tk appname command queries or changes the application name: set myname [tk appname] tk appname aNewName In Tk 3.6 and earlier, you have to use the winfo name command to get the name of the application: set myname [winfo name .] Send and X Authority The send command relies on the X authority mechanism for authorization. A command is rejected by the target interpreter if you do not have X authority set up. There are two ways around this problem. First, you can disable the access check by compiling the tkSend.c file with the -DTK_NO_SECURITY compile flag. If you must worry about malicious programs that send your programs commands, then you should not do this. The second option is to start your X server with its -auth flag, which initializes the X authority mechanism. The details vary depending on your X server, and most modern X servers do this automatically. The general picture is that you generate a pseudo-random string and store it into a file, which is usually named ~/.Xauthority and must be readable only by your account. The -auth flag specifies the name of this file to the X server. Each X application reads this file and sends the contents to the X server when opening the connection to the server. If the contents match what the server read when it started, then the connection is allowed. The system is slightly more complicated than described here. The file actually contains a sequence of records to support multiple displays and client hosts. Consult your local X guru or the documentation for the details particular to your system.  | Your xhost list must be clear. |
Tk also requires that the xhost list be empty. The xhost mechanism is the old, not-so-secure authentication mechanism in X. With xhost you allow all programs on a list of hosts to connect to your display. The problem with this is that multiuser workstations allow remote login, so essentially anybody could log in to a workstation on the xhost list and gain access to your display. The Xauthority mechanism is much stronger because it restricts access to your account, or to accounts that you explicitly give a secret token to. The problem is that even if Xauthority is set up, the user or a program can turn on xhosts and open up access to your display. If you run the xhost program with no argument, it reports the status and what hosts are on the list. The following output is generated when access control is restricted, but programs running on sage are allowed to connect to the display: exec xhost => Access control enabled: all hosts being restricted sage This is not good enough for Tk send. It will fail because sage is on the list. I work in an environment where old scripts and programs are constantly adding things to my xhost list for reasons that are no longer valid. I developed a version of send that checks for errors and then does the following to clean out the xhost list. You have to enable access control and then explicitly remove any hosts on the list. These are reported after an initial line that says whether or not hosts are restricted: xhost - ;# enable access control in general foreach host [lrange [split [exec xhost] \n] 1 end] { exec xhost -$host ;# clear out exceptions } | 
