<html><title>-</title><body BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#330088" ALINK="#FF0044"><H1>Plumbing and Other Utilities</H1><DL><DD><I>Rob Pike<br>Bell Laboratories, Murray Hill, NJ, 07974</I></DL><DL><DD><H4>ABSTRACT</H4><br> <br>Plumbing is a new mechanism for inter-process communication in Plan 9,specifically the passing of messages between interactive programs as part ofthe user interface.Although plumbing shares some properties with familiar notionssuch as cut and paste,it offers a more general data exchange mechanism without imposinga particular user interface.<br> <br>The core of the plumbing system is a program called the<I>plumber</I>,which handles all messages and dispatches and reformats themaccording to configuration rules written in a special-purpose language.This approach allows the contents and context of a piece of data to define howit is handled.Unlike with drag and drop or cut and paste,the user doesn't need to deliver the data;the contents of a plumbing message, as interpreted by the plumbing rules,determine its destination.<br> <br>The plumber has an unusual architecture: it is a language-driven file server.This design has distinct advantages.It makes plumbing easy to add to an existing, Unix-like command environment;it guarantees uniform handling of inter-application messages;it off-loads from those applications most of the work of extracting and dispatching messages;and it works transparently across a network.</DL><H4>Introduction</H4><br> <br>Data moves from program to program in myriad ways.Command-line arguments,shell pipe lines,cut and paste,drag and drop, and other user interface techniques all provide some formof interprocess communication.Then there are tricks associated with special domains,such as HTML hyperlinks or the heuristics mail readersuse to highlight URLs embedded in mail messages.Some systems provide implicit ways to automate the attachment of program to data­thebest known examples are probably the resource forks in MacOS and thefile name extension `associations' in Microsoft Windows­but in practicehumans must too often carry their data from program to program.<br> <br>Why should a human do the work?Usually there is one obvious thing to do with a piece of data,and the data itself suggests what this is.Resource forks and associations speak to this issue directly, but statically and narrowly and withlittle opportunity to control the behavior.Mechanisms with more generality,such as cut and paste or drag and drop, demand too much manipulation bythe user and are (therefore) too error-prone.<br> <br>We want a system that, given a piece of data,hands it to the appropriate application by default with little or no human intervention,while still permitting the user to override the defaults if desired.<br> <br>The plumbing system is an attempt to address some of these issues in a single,coherent, central way.It provides a mechanism forformatting and sending arbitrary messages between applications,typically interactive programs such as text editors, web browsers, and the window system,under the control of a central message-handling server called the<I>plumber</I>.Interactive programs provide application-specific connections to the plumber,triggering with minimal user action the transfer of data or control to other programs.The result is similar to a hypertext system in which all the links are implicit,extracted automatically by examining the data and the user's actions.It obviatescut and paste and other such hand-driven interprocess communication mechanisms.Plumbing delivers the goods to the right place automatically.<H4>Overview</H4><br> <br>The plumber is implemented as a Plan 9 file server [Pike93];programs send messages by writing them to the plumber's file<TT>/mnt/plumb/send</TT>,and receive messages by reading them from<I>ports</I>,which are other plumber files in<TT>/mnt/plumb</TT>.For example,<TT>/mnt/plumb/edit</TT>is by convention the file from which a text editor reads messages requesting it toopen and display a file for editing.(See Figure 1.)<DL><DT><DD><TT><PRE><br><img src="-.14230.gif"><br></PRE></TT></DL><DL><DT><DT> <DD>Figure 1. The plumber controls the flow of messages between applications.Programs write to the file<TT>send</TT>and receive on `ports' of various names representing services such as<TT>edit</TT>or<TT>web</TT>.Although the figure doesn't illustrate it, some programs may both send and receive messages,and some ports are read by multiple applications.<br> <br></dl><br> <br>The plumber takes messages from the<TT>send</TT>file and interprets their contents using rules defined bya special-purpose pattern-action language.The language specifies any rewriting of the message that is to be done by the plumberand defines how to dispose of a message, such as by sending it to a port orstarting a new process to handle it.<br> <br>The behavior is best described by example.Imagine that the user has, in a terminal emulator window,just run a compilation that has failed:<DL><DT><DD><TT><PRE>% makecc -c rmstar.crmstar.c:32: syntax error...</PRE></TT></DL>The user points the typing cursor somewhere in the string<TT>rmstar.c:32:</TT>and executes the<TT>plumb</TT>menu entry.This causes the terminal emulator to format a plumbing messagecontaining the entire string surrounding the cursor,<TT>rmstar:32:</TT>,and to write it to<TT>/mnt/plumb/send</TT>.The plumber receives this message and compares it sequentially to the variouspatterns in its configuration.Eventually, it will find one that breaks the string into pieces,<TT>rmstar.c</TT>,a colon,<TT>32</TT>,and the final colon.Other associated patterns verify that<TT>rmstar.c</TT>is a file in the current directory of the program generatingthe message, and that<TT>32</TT>looks like a line number within it.The plumber rewrites the message,setting the data to the string<TT>rmstar.c</TT>and attaching an indication that<TT>32</TT>is a line number to display.Finally, it sends the resulting message to the<TT>edit</TT>port.The text editor picks up the message, opens<TT>rmstar.c</TT>(if it's not already open) and highlights line 32, the location of the syntax error.<br> <br>From the user's point of view, this process is simple: the error message appears,it is `plumbed', and the editor jumps to the problem.<br> <br>Of course, there are many different ways to cause compiler messages topop up the source of an error,but the design of the plumber addresses more general issues than the specificgoal of shortening the compile/debug/edit cycle.It facilitates the general exchange of data among programs, interactive or otherwise,throughout the environment, and itsarchitecture­a central, language-driven file server­althoughunusual, has distinct advantages.It makes plumbing easy to add to an existing, Unix-like command environment;it guarantees uniform handling of inter-application messages;it off-loads from those applications most of the work of extracting and dispatching messages;and it works transparently and effortlessly across a network.<br> <br>This paper is organized bottom-up, beginning with the format of the messagesand proceeding through the plumbing language, the handling of messages,and the interactive user interface.The last sections discuss the implications of the designand compare the plumbing system to other environments thatprovide similar services.<H4>Format of messages</H4><br> <br>Since the language that controls the plumber is defined in terms of thecontents of plumbing messages, we begin by describing their layout.<br> <br>Plumbing messages have a fixed-format textualheader followed by a free-format data section.The header consists of six lines of text, in set order,each specifying a property of the message.Any line may be blank except the last, which is the length of the data portion of themessage, as a decimal string.The lines are, in order:<DL><DT><DT> <DD>The source application, the name of the program generating the message.<DT><DT> <DD>The destination port, the name of the port to which the messages should be sent.<DT><DT> <DD>The working directory in which the message was generated.<DT><DT> <DD>The type of the data, analogous to a MIME type, such as<TT>text</TT>or<TT>image/gif</TT>.<DT><DT> <DD>Attributes of the message, given as blank-separated<I>name<TT>=</TT>value</I>pairs.The values may be quoted to protectblanks or quotes; values may not contain newlines.<DT><DT> <DD>The length of the data section, in bytes.</dl><br> <br>Here is a sample message, one that (conventionally) tells the editor to open the file<TT>/usr/rob/src/mem.c</TT>and display line27 within it:<DL><DT><DD><TT><PRE>plumbtestedit/usr/rob/srctextaddr=275mem.c</PRE></TT></DL>Because in general it need not be text, the data section of the message has no terminating newline.<br> <br>A library interface simplifies the processing of messages by translating themto and from a data structure,<TT>Plumbmsg</TT>,defined like this:<DL><DT><DD><TT><PRE>typedef struct Plumbattr Plumbattr;typedef struct Plumbmsg Plumbmsg; struct Plumbmsg{ char *src; /* source application */ char *dst; /* destination port */ char *wdir; /* working directory */ char *type; /* type of data */ Plumbattr *attr; /* attribute list */ int ndata; /* #bytes of data */ char *data;}; struct Plumbattr{ char *name; char *value; Plumbattr *next;};</PRE></TT></DL>The library also includes routines to send a message, receive a message,manipulate the attribute list, and so on.<H4>The Language</H4><br> <br>An instance of the plumber runs for each user on each terminal or workstation.Itbegins by reading its rules from the file<TT>lib/plumbing</TT>in the user's home directory,which in turn may use<TT>include</TT>statements to interpolate macro definitions andrules from standard plumbing rule libraries stored in<TT>/sys/lib/plumb</TT>.<br> <br>The rules control the processing of messages.They are written ina pattern-action language comprising a sequence of blank-line-separated<I>rule</I><I>sets</I>,each of which contains one or more<I>patterns</I>followed by one or more<I>actions</I>.Each incoming message is compared against the rule sets in order.If all the patterns within a rule set succeed,one of the associated actions is taken and processing completes.<br> <br>The syntax of the language is straightforward.Each rule (pattern or action) has three components, separated by white space:an<I>object</I>,a<I>verb</I>,and optional<I>arguments</I>.The objectidentifies a part of the message, such asthe source application(<TT>src</TT>),or the dataportion of the message(<TT>data</TT>),or the rule's own arguments(<TT>arg</TT>);or it is the keyword<TT>plumb</TT>,which introduces an action.The verb specifies an operation to perform on the object, such as the word`<TT>is</TT>'to require precise equality between the object and the argument, or`<TT>isdir</TT>'to require that the object be the name of a directory.<br> <br>For instance, this rule set sends messages containing the names of filesending in<TT>.gif</TT>,<TT>.jpg</TT>,etc. to a program,<TT>page</TT>,to display them; it is analogous to a Windows association rule:<DL><DT><DD><TT><PRE># image files go to pagetype is textdata matches '[a-zA-Z0-9_\-./]+'data matches '([a-zA-Z0-9_\-./]+)\.(jpe?g|gif|bit|tiff|ppm)'arg isfile $0plumb to imageplumb client page -wi</PRE></TT></DL>(Lines beginning with<TT>#</TT>are commentary.)Consider how this rule handles the following message, annotated down the left column for clarity:<DL><DT><DD><TT><PRE><I>src</I> plumbtest<I>dst</I><I>wdir</I> /usr/rob/pics<I>type</I> text<I>attr</I><I>ndata</I> 9<I>data</I> horse.gif</PRE></TT></DL>The<TT>is</TT>verb specifies a precise match, and the<TT>type</TT>field of the message is the string<TT>text</TT>,so the first pattern succeeds.The<TT>matches</TT>verb invokes a regular expression pattern match of the object (here<TT>data</TT>)against the argument pattern.Both<TT>matches</TT>patterns in this rule set will succeed, and in the process set the variables<TT>$0</TT>to the matched string,<TT>$1</TT>to the first parenthesized submatch, and so on (analogous to<TT>&</TT>,<TT>1</TT>,etc. in<TT>ed</TT>'sregular expressions).The pattern<TT>arg</TT><TT>isfile</TT><TT>$0</TT>verifies that the named file,<TT>horse.gif</TT>,is an actual file in the directory<TT>/usr/rob/pics</TT>.If all the patterns succeed, one of the actions will be executed.<br> <br>There are two actions in this rule set.The<TT>plumb</TT><TT>to</TT>rule specifies<TT>image</TT>as the destination port of the message.By convention, the plumber mounts its services in the directory<TT>/mnt/plumb</TT>,so in this case if the file<TT>/mnt/plumb/image</TT>has been opened, the message will be made available to the program reading from it.Note that the message does not name a port, but the rule set that matchesthe message does, and that is sufficient to dispatch the message.If on the other hand a message matches no rule but has an explicit port mentioned,that too is sufficient.<br> <br>If no client has opened the<TT>image</TT>port,that is, if the program<TT>page</TT>is not already running, the<TT>plumb</TT><TT>client</TT>action gives the execution script to start the applicationand send the message on its way; the<TT>-wi</TT>arguments tell<TT>page</TT>to create a window and to receive its initial arguments from the plumbing port.The process by which the plumber starts a program is described in more detail in the next section.<br> <br>It may seem odd that there are two<TT>matches</TT>rules in this example.The reason is related to the way the plumber can use the rules themselvesto refine the<I>data</I>in the message, somewhat in the manner of Structural Regular Expressions [Pike87a].For example, consider what happens if the cursor is at the last character of<DL><DT><DD><TT><PRE>% make nightmare>horse.gif</PRE></TT></DL>and the user asks to plumb what the cursor is pointing at.The program creating the plumbingmessage­in this case the terminal emulator running the window­can send theentire white-space-delimited string<TT>nightmare>horse.gif</TT>or even the entire line, and the combination of<TT>matches</TT>rules can determine that the user was referring to the string<TT>horse.gif</TT>.The user could of course select the entire string<TT>horse.gif</TT>,but it's more convenient just to point in the general location and let the machinefigure out what should be done.The process is as follows.<br> <br>The application generating the message adds a special attribute to the message, named<TT>click</TT>,whose numerical value is the offset of the cursor­the selection point­within the data string.This attribute tells the plumber two things:first, that the regular expressions in<TT>matches</TT>rules should be used to identify the relevant data;and second, approximately where the relevant data lies.The plumber will then use the first<TT>matches</TT>pattern to identify the longest leftmost match that touches the cursor, which will extract the string<TT>horse.gif</TT>,and the second pattern will then verify that that names a picture file.The rule set succeeds and the data is winnowed to the matching substringbefore being sent to its destination.<br> <br>Each<TT>matches</TT>pattern within a given rule set must match the same portion of the string, whichguarantees that the rule set fails to match a string for which thesecond pattern matches only a portion.For instance, our example rule set should not execute if the data is the string<TT>horse.gift</TT>,and although the first pattern will match<TT>horse.gift</TT>,the second will match only<TT>horse.gif</TT>and the rule set will fail.<br> <br>The same approach of multiple<TT>matches</TT>rules can be used to exclude, for instance, a terminal period froma file name or URL, so a file name or URL at the end of a sentence is recognized properly.<br> <br>If a<TT>click</TT>attribute is not specified, all patterns must match the entire string,so the user has an option:he or she may select exactly what data to send,or may instead indicate where the data is by clicking the selection button on the mouseand letting the machine locate the URL or image file name within the text.In other words,the user can control the contents of the message precisely when required,but the default, simplest action in the user interface does the right thing most of the time.<H4>How Messages are Handled in the Plumber</H4><br> <br>An application creates a message header, fills in whatever fields it wishes to define,attaches the data, and writes the result to the file<TT>send</TT>in the plumber's service directory,<TT>/mnt/plumb</TT>.The plumber receives the message and applies the plumbing rules successively to it.When a rule set matches, the message is dispatched as indicated by that rule setand processing continues with the next message.If no rule set matches the message, the plumber indicates this by returning a writeerror to the application, that is, the write toLines 1–500 of 1407. Load more
<html> <title> - </title> <body BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#330088" ALINK="#FF0044"> <H1>Plumbing and Other Utilities </H1> <DL><DD><I>Rob Pike<br> Bell Laboratories, Murray Hill, NJ, 07974 </I></DL> <DL><DD><H4>ABSTRACT</H4> <br> <br> Plumbing is a new mechanism for inter-process communication in Plan 9, specifically the passing of messages between interactive programs as part of the user interface. Although plumbing shares some properties with familiar notions such as cut and paste, it offers a more general data exchange mechanism without imposing a particular user interface. <br> <br> The core of the plumbing system is a program called the <I>plumber</I>, which handles all messages and dispatches and reformats them according to configuration rules written in a special-purpose language. This approach allows the contents and context of a piece of data to define how it is handled. Unlike with drag and drop or cut and paste, the user doesn't need to deliver the data; the contents of a plumbing message, as interpreted by the plumbing rules, determine its destination. <br> <br> The plumber has an unusual architecture: it is a language-driven file server. This design has distinct advantages. It makes plumbing easy to add to an existing, Unix-like command environment; it guarantees uniform handling of inter-application messages; it off-loads from those applications most of the work of extracting and dispatching messages; and it works transparently across a network. </DL> <H4>Introduction </H4> <br> <br> Data moves from program to program in myriad ways. Command-line arguments, shell pipe lines, cut and paste, drag and drop, and other user interface techniques all provide some form of interprocess communication. Then there are tricks associated with special domains, such as HTML hyperlinks or the heuristics mail readers use to highlight URLs embedded in mail messages. Some systems provide implicit ways to automate the attachment of program to data­the best known examples are probably the resource forks in MacOS and the file name extension `associations' in Microsoft Windows­but in practice humans must too often carry their data from program to program. <br> <br> Why should a human do the work? Usually there is one obvious thing to do with a piece of data, and the data itself suggests what this is. Resource forks and associations speak to this issue directly, but statically and narrowly and with little opportunity to control the behavior. Mechanisms with more generality, such as cut and paste or drag and drop, demand too much manipulation by the user and are (therefore) too error-prone. <br> <br> We want a system that, given a piece of data, hands it to the appropriate application by default with little or no human intervention, while still permitting the user to override the defaults if desired. <br> <br> The plumbing system is an attempt to address some of these issues in a single, coherent, central way. It provides a mechanism for formatting and sending arbitrary messages between applications, typically interactive programs such as text editors, web browsers, and the window system, under the control of a central message-handling server called the <I>plumber</I>. Interactive programs provide application-specific connections to the plumber, triggering with minimal user action the transfer of data or control to other programs. The result is similar to a hypertext system in which all the links are implicit, extracted automatically by examining the data and the user's actions. It obviates cut and paste and other such hand-driven interprocess communication mechanisms. Plumbing delivers the goods to the right place automatically. <H4>Overview </H4> <br> <br> The plumber is implemented as a Plan 9 file server [Pike93]; programs send messages by writing them to the plumber's file <TT>/mnt/plumb/send</TT>, and receive messages by reading them from <I>ports</I>, which are other plumber files in <TT>/mnt/plumb</TT>. For example, <TT>/mnt/plumb/edit</TT> is by convention the file from which a text editor reads messages requesting it to open and display a file for editing. (See Figure 1.) <DL><DT><DD><TT><PRE> <br><img src="-.14230.gif"><br> </PRE></TT></DL> <DL> <DT><DT> <DD> Figure 1. The plumber controls the flow of messages between applications. Programs write to the file <TT>send</TT> and receive on `ports' of various names representing services such as <TT>edit</TT> or <TT>web</TT>. Although the figure doesn't illustrate it, some programs may both send and receive messages, and some ports are read by multiple applications. <br> <br> </dl> <br> <br> The plumber takes messages from the <TT>send</TT> file and interprets their contents using rules defined by a special-purpose pattern-action language. The language specifies any rewriting of the message that is to be done by the plumber and defines how to dispose of a message, such as by sending it to a port or starting a new process to handle it. <br> <br> The behavior is best described by example. Imagine that the user has, in a terminal emulator window, just run a compilation that has failed: <DL><DT><DD><TT><PRE> % make cc -c rmstar.c rmstar.c:32: syntax error ... </PRE></TT></DL> The user points the typing cursor somewhere in the string <TT>rmstar.c:32:</TT> and executes the <TT>plumb</TT> menu entry. This causes the terminal emulator to format a plumbing message containing the entire string surrounding the cursor, <TT>rmstar:32:</TT>, and to write it to <TT>/mnt/plumb/send</TT>. The plumber receives this message and compares it sequentially to the various patterns in its configuration. Eventually, it will find one that breaks the string into pieces, <TT>rmstar.c</TT>, a colon, <TT>32</TT>, and the final colon. Other associated patterns verify that <TT>rmstar.c</TT> is a file in the current directory of the program generating the message, and that <TT>32</TT> looks like a line number within it. The plumber rewrites the message, setting the data to the string <TT>rmstar.c</TT> and attaching an indication that <TT>32</TT> is a line number to display. Finally, it sends the resulting message to the <TT>edit</TT> port. The text editor picks up the message, opens <TT>rmstar.c</TT> (if it's not already open) and highlights line 32, the location of the syntax error. <br> <br> From the user's point of view, this process is simple: the error message appears, it is `plumbed', and the editor jumps to the problem. <br> <br> Of course, there are many different ways to cause compiler messages to pop up the source of an error, but the design of the plumber addresses more general issues than the specific goal of shortening the compile/debug/edit cycle. It facilitates the general exchange of data among programs, interactive or otherwise, throughout the environment, and its architecture­a central, language-driven file server­although unusual, has distinct advantages. It makes plumbing easy to add to an existing, Unix-like command environment; it guarantees uniform handling of inter-application messages; it off-loads from those applications most of the work of extracting and dispatching messages; and it works transparently and effortlessly across a network. <br> <br> This paper is organized bottom-up, beginning with the format of the messages and proceeding through the plumbing language, the handling of messages, and the interactive user interface. The last sections discuss the implications of the design and compare the plumbing system to other environments that provide similar services. <H4>Format of messages </H4> <br> <br> Since the language that controls the plumber is defined in terms of the contents of plumbing messages, we begin by describing their layout. <br> <br> Plumbing messages have a fixed-format textual header followed by a free-format data section. The header consists of six lines of text, in set order, each specifying a property of the message. Any line may be blank except the last, which is the length of the data portion of the message, as a decimal string. The lines are, in order: <DL> <DT><DT> <DD> The source application, the name of the program generating the message. <DT><DT> <DD> The destination port, the name of the port to which the messages should be sent. <DT><DT> <DD> The working directory in which the message was generated. <DT><DT> <DD> The type of the data, analogous to a MIME type, such as <TT>text</TT> or <TT>image/gif</TT>. <DT><DT> <DD> Attributes of the message, given as blank-separated <I>name<TT>=</TT>value</I> pairs. The values may be quoted to protect blanks or quotes; values may not contain newlines. <DT><DT> <DD> The length of the data section, in bytes. </dl> <br> <br> Here is a sample message, one that (conventionally) tells the editor to open the file <TT>/usr/rob/src/mem.c</TT> and display line 27 within it: <DL><DT><DD><TT><PRE> plumbtest edit /usr/rob/src text addr=27 5 mem.c </PRE></TT></DL> Because in general it need not be text, the data section of the message has no terminating newline. <br> <br> A library interface simplifies the processing of messages by translating them to and from a data structure, <TT>Plumbmsg</TT>, defined like this: <DL><DT><DD><TT><PRE> typedef struct Plumbattr Plumbattr; typedef struct Plumbmsg Plumbmsg; struct Plumbmsg { char *src; /* source application */ char *dst; /* destination port */ char *wdir; /* working directory */ char *type; /* type of data */ Plumbattr *attr; /* attribute list */ int ndata; /* #bytes of data */ char *data; }; struct Plumbattr { char *name; char *value; Plumbattr *next; }; </PRE></TT></DL> The library also includes routines to send a message, receive a message, manipulate the attribute list, and so on. <H4>The Language </H4> <br> <br> An instance of the plumber runs for each user on each terminal or workstation. It begins by reading its rules from the file <TT>lib/plumbing</TT> in the user's home directory, which in turn may use <TT>include</TT> statements to interpolate macro definitions and rules from standard plumbing rule libraries stored in <TT>/sys/lib/plumb</TT>. <br> <br> The rules control the processing of messages. They are written in a pattern-action language comprising a sequence of blank-line-separated <I>rule</I> <I>sets</I>, each of which contains one or more <I>patterns</I> followed by one or more <I>actions</I>. Each incoming message is compared against the rule sets in order. If all the patterns within a rule set succeed, one of the associated actions is taken and processing completes. <br> <br> The syntax of the language is straightforward. Each rule (pattern or action) has three components, separated by white space: an <I>object</I>, a <I>verb</I>, and optional <I>arguments</I>. The object identifies a part of the message, such as the source application (<TT>src</TT>), or the data portion of the message (<TT>data</TT>), or the rule's own arguments (<TT>arg</TT>); or it is the keyword <TT>plumb</TT>, which introduces an action. The verb specifies an operation to perform on the object, such as the word `<TT>is</TT>' to require precise equality between the object and the argument, or `<TT>isdir</TT>' to require that the object be the name of a directory. <br> <br> For instance, this rule set sends messages containing the names of files ending in <TT>.gif</TT>, <TT>.jpg</TT>, etc. to a program, <TT>page</TT>, to display them; it is analogous to a Windows association rule: <DL><DT><DD><TT><PRE> # image files go to page type is text data matches '[a-zA-Z0-9_\-./]+' data matches '([a-zA-Z0-9_\-./]+)\.(jpe?g|gif|bit|tiff|ppm)' arg isfile $0 plumb to image plumb client page -wi </PRE></TT></DL> (Lines beginning with <TT>#</TT> are commentary.) Consider how this rule handles the following message, annotated down the left column for clarity: <DL><DT><DD><TT><PRE> <I>src</I> plumbtest <I>dst</I> <I>wdir</I> /usr/rob/pics <I>type</I> text <I>attr</I> <I>ndata</I> 9 <I>data</I> horse.gif </PRE></TT></DL> The <TT>is</TT> verb specifies a precise match, and the <TT>type</TT> field of the message is the string <TT>text</TT>, so the first pattern succeeds. The <TT>matches</TT> verb invokes a regular expression pattern match of the object (here <TT>data</TT>) against the argument pattern. Both <TT>matches</TT> patterns in this rule set will succeed, and in the process set the variables <TT>$0</TT> to the matched string, <TT>$1</TT> to the first parenthesized submatch, and so on (analogous to <TT>&</TT>, <TT>1</TT>, etc. in <TT>ed</TT>'s regular expressions). The pattern <TT>arg</TT> <TT>isfile</TT> <TT>$0</TT> verifies that the named file, <TT>horse.gif</TT>, is an actual file in the directory <TT>/usr/rob/pics</TT>. If all the patterns succeed, one of the actions will be executed. <br> <br> There are two actions in this rule set. The <TT>plumb</TT> <TT>to</TT> rule specifies <TT>image</TT> as the destination port of the message. By convention, the plumber mounts its services in the directory <TT>/mnt/plumb</TT>, so in this case if the file <TT>/mnt/plumb/image</TT> has been opened, the message will be made available to the program reading from it. Note that the message does not name a port, but the rule set that matches the message does, and that is sufficient to dispatch the message. If on the other hand a message matches no rule but has an explicit port mentioned, that too is sufficient. <br> <br> If no client has opened the <TT>image</TT> port, that is, if the program <TT>page</TT> is not already running, the <TT>plumb</TT> <TT>client</TT> action gives the execution script to start the application and send the message on its way; the <TT>-wi</TT> arguments tell <TT>page</TT> to create a window and to receive its initial arguments from the plumbing port. The process by which the plumber starts a program is described in more detail in the next section. <br> <br> It may seem odd that there are two <TT>matches</TT> rules in this example. The reason is related to the way the plumber can use the rules themselves to refine the <I>data</I> in the message, somewhat in the manner of Structural Regular Expressions [Pike87a]. For example, consider what happens if the cursor is at the last character of <DL><DT><DD><TT><PRE> % make nightmare>horse.gif </PRE></TT></DL> and the user asks to plumb what the cursor is pointing at. The program creating the plumbing message­in this case the terminal emulator running the window­can send the entire white-space-delimited string <TT>nightmare>horse.gif</TT> or even the entire line, and the combination of <TT>matches</TT> rules can determine that the user was referring to the string <TT>horse.gif</TT>. The user could of course select the entire string <TT>horse.gif</TT>, but it's more convenient just to point in the general location and let the machine figure out what should be done. The process is as follows. <br> <br> The application generating the message adds a special attribute to the message, named <TT>click</TT>, whose numerical value is the offset of the cursor­the selection point­within the data string. This attribute tells the plumber two things: first, that the regular expressions in <TT>matches</TT> rules should be used to identify the relevant data; and second, approximately where the relevant data lies. The plumber will then use the first <TT>matches</TT> pattern to identify the longest leftmost match that touches the cursor, which will extract the string <TT>horse.gif</TT>, and the second pattern will then verify that that names a picture file. The rule set succeeds and the data is winnowed to the matching substring before being sent to its destination. <br> <br> Each <TT>matches</TT> pattern within a given rule set must match the same portion of the string, which guarantees that the rule set fails to match a string for which the second pattern matches only a portion. For instance, our example rule set should not execute if the data is the string <TT>horse.gift</TT>, and although the first pattern will match <TT>horse.gift</TT>, the second will match only <TT>horse.gif</TT> and the rule set will fail. <br> <br> The same approach of multiple <TT>matches</TT> rules can be used to exclude, for instance, a terminal period from a file name or URL, so a file name or URL at the end of a sentence is recognized properly. <br> <br> If a <TT>click</TT> attribute is not specified, all patterns must match the entire string, so the user has an option: he or she may select exactly what data to send, or may instead indicate where the data is by clicking the selection button on the mouse and letting the machine locate the URL or image file name within the text. In other words, the user can control the contents of the message precisely when required, but the default, simplest action in the user interface does the right thing most of the time. <H4>How Messages are Handled in the Plumber </H4> <br> <br> An application creates a message header, fills in whatever fields it wishes to define, attaches the data, and writes the result to the file <TT>send</TT> in the plumber's service directory, <TT>/mnt/plumb</TT>. The plumber receives the message and applies the plumbing rules successively to it. When a rule set matches, the message is dispatched as indicated by that rule set and processing continues with the next message. If no rule set matches the message, the plumber indicates this by returning a write error to the application, that is, the write to