home *** CD-ROM | disk | FTP | other *** search
/ Netrunner 2004 October / NETRUNNER0410.ISO / regular / ActivePerl-5.8.4.810-MSWin32-x86.msi / _956dc61cf890ed85df3fe49b1348c6c4 < prev    next >
Encoding:
Text File  |  2004-06-01  |  4.5 KB  |  120 lines
  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.  
  120.