src/drafts/scripting

   1 The design
   2
   3 I. Key Factors
   4 There are several aspects to deal with when adding scripting support to
   5 Screen:
   6 1. The set of information to expose.
   7 2. The command interface to provide.
   8 3. The hook on interesting events in Screen.
   9 4. The ability to do run asynchronously to Screen itself.
  10
  11 A. Query & control interface
  12
  13 Currently, screen provides a way to control a running session through the -X
  14 command switch, which sends the specified command through the sever socket.
  15 It's quite useful and can already do automation to some degree, (e.g. [1]).
  16 However, the problem is that, there is no way to get enough feedback to make
  17 decision in your script in such a scheme. The first job is to provide an
  18 interface for scripts to query internal status of Screen. The second job is to
  19 provide an interface to control Screen, with reasonable feedback.
  20
  21 B. Event hooking
  22
  23 When the internal status of Screen changed, we say that an event happened.
  24 Events are also interesting to scripts, but are not covered by the query
  25 interface. A hook / callback system is needed to notify scripts about
  26 interested events. With the callback that triggers before an event, the script
  27 should be able to stop the event from happening.
  28
  29 C. Asynchronous scripting
  30
  31 So far, with the described scripting support, we can write small functions
  32 that provide enhanced functionality to a screen command, or write event
  33 handler that handles interested events. But we are restricted to finish our
  34 work quickly. The problem is that, Screen itself is a single threaded
  35 application, utilizing asynchronous I/O to provide services to all windows
  36 running inside. So you simply can not do time-consuming work in any of the
  37 processing path, including the scripts.
  38
  39 Sometimes we may need to wait for something in a script, such as emulating
  40 Expect in a Screen script [2]. The core of this use case is to wait for an
  41 output pattern and react upon it. One possible way is to provide an event
  42 callback for it. But it's not a pleasant way to do a series of interaction.
  43 A natural solution is to make the script able to run asynchronously to Screen
  44 itself.
  45
  46 [1] http://github.com/rblackwe/yapc--na-2007--making-an-ajax-gui-for-gnu-screen
  47 [2] http://lists.gnu.org/archive/html/screen-users/2009-05/msg00006.html
  48
  49
  50 II. The query & control interface
  51
  52 There are several kinds of objects that may be interested to scripts.
  53
  54 A. Display
  55
  56 Stands for a user interface.
  57
  58 Properties:
  59 tty: The tty that this attach runs on.
  60 term: The TERM env of that tty.
  61 fore: The fore window.
  62 other: List of windows other than the fore.
  63 width: As the name suggests
  64 height: As the name suggests
  65 user: The owner of this display.
  66 layout: Active layout on this diaplay.