1send(3)               User Contributed Perl Documentation              send(3)
2
3
4

NAME

6       send - Execute a command in a different application
7

SYNOPSIS

9           $result = $widget->send(?options,?app=>cmd?arg arg ...?)
10

DESCRIPTION

12       This method arranges for cmd (and args) to be 'sent' to the application
13       named by app.  It returns the result or an error (hence above should
14       probably be 'wrapped' in eval{} and $@ tested).  App may be the name of
15       any application whose main window is on the display containing the
16       sender's main window;  it need not be within the same process.  If no
17       arg arguments are present, then the string to be sent is contained
18       entirely within the cmd argument.  If one or more args are present,
19       they are concatenated separated by white space to form the string to be
20       sent.
21
22       If the initial arguments of the call begin with ``-'' they are treated
23       as options.  The following options are currently defined:
24
25       -async
26           Requests asynchronous invocation.  In this case the send command
27           will complete immediately without waiting for cmd to complete in
28           the target application;  no result will be available and errors in
29           the sent command will be ignored.  If the target application is in
30           the same process as the sending application then the -async option
31           is ignored.
32
33       --  Serves no purpose except to terminate the list of options.  This
34           option is needed only if app could contain a leading ``-''
35           character.
36

APPLICATION NAMES

38       The name of an application is set initially from the name of the
39       program or script that created the application.  You can query and
40       change the name of an application with the appname method.
41

WHAT IS A SEND

43       The send mechanism was designed to allow Tcl/Tk applications to send
44       Tcl Scripts to each other. This does not map very well onto perl/Tk.
45       Perl/Tk "sends" a string to app, what happens as a result of this
46       depends on the receiving application. If the other application is a
47       Tcl/Tk4.*  application it will be treated as a Tcl Script. If the
48       "other" application is perl/Tk application (including sends to self)
49       then the string is passed as an argument to a method call of the
50       following form:
51
52       $mainwindow->Receive(string);
53
54       There is a default (AutoLoaded) Tk::Receive which returns an error to
55       the sending application. A particular application may define its own
56       Receive method in any class in MainWindow's inheritance tree to do
57       whatever it sees fit. For example it could eval the string, possibly in
58       a Safe "compartment".
59
60       If a Tcl/Tk application "sends" anything to a perl/Tk application then
61       the perl/Tk application would have to attempt to interpret the incoming
62       string as a Tcl Script. Simple cases are should not be too hard to
63       emulate (split on white space and treat first element as "command" and
64       other elements as arguments).
65

SECURITY

67       The send command is potentially a serious security loophole, since any
68       application that can connect to your X server can send scripts to your
69       applications. Hence the default behaviour outlined above.  (With the
70       availability of Safe it may make sense to relax default behaviour a
71       little.)
72
73       Unmonitored eval'ing of these incoming "scripts" can cause perl to read
74       and write files and invoke subprocesses under your name.  Host-based
75       access control such as that provided by xhost is particularly insecure,
76       since it allows anyone with an account on particular hosts to connect
77       to your server, and if disabled it allows anyone anywhere to connect to
78       your server.  In order to provide at least a small amount of security,
79       core Tk checks the access control being used by the server and rejects
80       incoming sends unless (a) xhost-style access control is enabled (i.e.
81       only certain hosts can establish connections) and (b) the list of
82       enabled hosts is empty.  This means that applications cannot connect to
83       your server unless they use some other form of authorization such as
84       that provide by xauth.
85

SEE ALSO

87       "eval" in perlfunc, Safe, system's administrator/corporate security
88       guidelines etc.
89

KEYWORDS

91       application, name, remote execution, security, send
92
93
94
95perl v5.16.3                      2014-06-10                           send(3)
Impressum