Commit | Line | Data |
---|---|---|
86530b38 AT |
1 | # Copyright (c) 1990-1994 The Regents of the University of California. |
2 | # Copyright (c) 1994-1996 Sun Microsystems, Inc. | |
3 | # See the file "license.terms" for information on usage and redistribution | |
4 | # of this file, and for a DISCLAIMER OF ALL WARRANTIES. | |
5 | # | |
6 | # | |
7 | ||
8 | =head1 NAME | |
9 | ||
10 | send - Execute a command in a different application | |
11 | ||
12 | =for category Tk Generic Methods | |
13 | ||
14 | =head1 SYNOPSIS | |
15 | ||
16 | S< >I<$result> = I<$widget>-E<gt>B<send>(?I<options>,?I<app>=E<gt>I<cmd>?I<arg arg ...>?) | |
17 | ||
18 | =head1 DESCRIPTION | |
19 | ||
20 | This method arranges for I<cmd> (and I<arg>s) to be 'sent' to the | |
21 | application named by I<app>. It returns the result or | |
22 | an error (hence above should probably be 'wrapped' in B<eval{}> and $@ tested). | |
23 | I<App> may be the name of any application whose main window is | |
24 | on the display containing the sender's main window; it need not | |
25 | be within the same process. | |
26 | If no I<arg> arguments are present, then the string to be sent | |
27 | is contained entirely within the I<cmd> argument. If one or | |
28 | more I<arg>s are present, they are concatenated separated by white space to | |
29 | form the string to be sent. | |
30 | ||
31 | If the initial arguments of the call begin with ``-'' | |
32 | they are treated as options. The following options are | |
33 | currently defined: | |
34 | ||
35 | =over 4 | |
36 | ||
37 | =item B<-async> | |
38 | ||
39 | Requests asynchronous invocation. In this case the B<send> | |
40 | command will complete immediately without waiting for I<cmd> | |
41 | to complete in the target application; no result will be available | |
42 | and errors in the sent command will be ignored. | |
43 | If the target application is in the same process as the sending | |
44 | application then the B<-async> option is ignored. | |
45 | ||
46 | =item B<--> | |
47 | ||
48 | Serves no purpose except to terminate the list of options. This | |
49 | option is needed only if I<app> could contain a leading ``-'' | |
50 | character. | |
51 | ||
52 | =back | |
53 | ||
54 | =head1 APPLICATION NAMES | |
55 | ||
56 | The name of an application is set initially from the name of the | |
57 | program or script that created the application. | |
58 | You can query and change the name of an application with the | |
59 | B<appname> method. | |
60 | ||
61 | =head1 WHAT IS A SEND | |
62 | ||
63 | The B<send> mechanism was designed to allow Tcl/Tk applications | |
64 | to send Tcl Scripts to each other. This does not map very well onto perl/Tk. | |
65 | Perl/Tk "sends" a string to I<app>, what happens as a result of this | |
66 | depends on the receiving application. If the other application is a Tcl/Tk4.* | |
67 | application it will be treated as a Tcl Script. If the "other" application is | |
68 | perl/Tk application (including sends to self) then the string is | |
69 | passed as an argument to a method call of the following form: | |
70 | ||
71 | I<$mainwindow>-E<gt>B<Receive(>I<string>); | |
72 | ||
73 | There is a default (AutoLoaded) B<Tk::Receive> which returns an error to the | |
74 | sending application. A particular application may define its own | |
75 | B<Receive> method in any class in B<MainWindow>'s inheritance tree | |
76 | to do whatever it sees fit. For example it could B<eval> the string, | |
77 | possibly in a B<Safe> "compartment". | |
78 | ||
79 | If a Tcl/Tk application "sends" anything to a perl/Tk application | |
80 | then the perl/Tk application would have to attempt to interpret the | |
81 | incoming string as a Tcl Script. Simple cases are should not be too hard to | |
82 | emulate (split on white space and treat first element as "command" and other | |
83 | elements as arguments). | |
84 | ||
85 | =head1 SECURITY | |
86 | ||
87 | The B<send> command is potentially a serious security loophole, | |
88 | since any application that can connect to your X server can send | |
89 | scripts to your applications. Hence the default behaviour outlined above. | |
90 | (With the availability of B<Safe> it may make sense to relax default behaviour | |
91 | a little.) | |
92 | ||
93 | Unmonitored B<eval>'ing of these incoming "scripts" can cause perl to | |
94 | read and write files and invoke subprocesses under your name. | |
95 | Host-based access control such as that provided by B<xhost> | |
96 | is particularly insecure, since it allows anyone with an account | |
97 | on particular hosts to connect to your server, and if disabled it | |
98 | allows anyone anywhere to connect to your server. | |
99 | In order to provide at least a small amount of | |
100 | security, core Tk checks the access control being used by the server | |
101 | and rejects incoming sends unless (a) B<xhost>-style access control | |
102 | is enabled (i.e. only certain hosts can establish connections) and (b) the | |
103 | list of enabled hosts is empty. | |
104 | This means that applications cannot connect to your server unless | |
105 | they use some other form of authorization | |
106 | such as that provide by B<xauth>. | |
107 | ||
108 | =head1 SEE ALSO | |
109 | ||
110 | Perl's B<eval> | |
111 | perl's B<Safe> Module | |
112 | system's administrator/corporate security guidelines etc. | |
113 | ||
114 | =head1 KEYWORDS | |
115 | ||
116 | application, name, remote execution, security, send | |
117 | ||
118 | =cut | |
119 |