+<p>
+The next example assumes that device_namer outputs two parts, the first being the device name, and the second being the name for an additional symbolic link. We now introduce the <em>%c{N}</em> substitution, which refers to part N of the output:
+</p>
+
+<blockquote><pre>KERNEL=="hda", PROGRAM="/bin/device_namer %k", NAME="%c{1}", SYMLINK+="%c{2}"</pre></blockquote>
+
+<p>
+The next example assumes that device_namer outputs one part for the device name, followed by any number of parts which will form additional symbolic links. We now introduce the <em>%c{N+}</em> substitution, which evaluates to part N, N+1, N+2, ... until the end of the output.
+</p>
+
+<blockquote><pre>KERNEL=="hda", PROGRAM="/bin/device_namer %k", NAME="%c{1}", SYMLINK+="%c{2+}"</pre></blockquote>
+
+<p>
+Output parts can be used in any assignment key, not only NAME and SYMLINK. The example below uses a fictional program to determine the Unix group which should own the device:
+</p>
+
+<blockquote><pre>KERNEL=="hda", PROGRAM="/bin/who_owns_device %k", GROUP="%c"</pre></blockquote>
+
+<a name="external-run"></a>
+<h3>Running external programs upon certain events</h3>
+
+<p>
+Yet another reason for writing udev rules is to run a particular program when a device is connected or disconnected. For example, you might want to execute a script to automatically download all of your photos from your digital camera when it is connected.
+</p>
+
+<p>
+Do not confuse this with the <em>PROGRAM</em> functionality described above. <em>PROGRAM</em> is used for running programs which produce device names (and they shouldn't do anything other than that). When those programs are being executed, the device node has not yet been created, so acting upon the device in any way is not possible.
+</p>
+
+<p>
+The functionality introduced here allows you to run a program after the device node is put in place. This program can act on the device, however it must not run for any extended period of time, because udev is effectively paused while these programs are running. One workaround for this limitation is to make sure your program immediately detaches itself.
+</p>
+
+<p>
+Here is an example rule which demonstrates the use of the <em>RUN</em> list assignment:
+</p>
+
+<blockquote><pre>KERNEL=="sdb", RUN+="/usr/bin/my_program"</pre></blockquote>
+
+<p>
+When <em>/usr/bin/my_program</em> is executed, various parts of the udev environment are available as environment variables, including key values such as <em>SUBSYSTEM</em>. You can also use the <em>ACTION</em> environment variable to detect whether the device is being connected or disconnected - ACTION will be either "add" or "remove" respectively.
+</p>
+
+<p>
+udev does not run these programs on any active terminal, and it does not execute them under the context of a shell. Be sure to ensure your program is marked executable, if it is a shell script ensure it starts with an appropriate <a href="http://en.wikipedia.org/wiki/Shebang_(Unix)">shebang</a> (e.g. <code>#!/bin/sh</code>), and do not expect any standard output to appear on your terminal.
+</p>
+
+<a name="env"></a>
+<h3>Environment interaction</h3>
+
+<p>
+udev provides an <em>ENV</em> key for environment variables which can be used for both matching and assignment.
+</p>
+
+<p>
+In the assignment case, you can set environment variables which you can then match against later. You can also set environment variables which can be used by any external programs invoked using the techniques mentioned above. A fictional example rule which sets an environment variable is shown below.
+</p>
+
+<blockquote><pre>KERNEL=="fd0", SYMLINK+="floppy", ENV{some_var}="value"</pre></blockquote>
+
+<p>
+In the matching case, you can ensure that rules only run depending on the value of an environment variable. Note that the environment that udev sees will not be the same user environment as you get on the console. A fictional rule involving an environment match is shown below.
+</p>
+
+<blockquote><pre>KERNEL=="fd0", ENV{an_env_var}=="yes", SYMLINK+="floppy"</pre></blockquote>
+
+<p>
+The above rule only creates the <em>/dev/floppy</em> link if $an_env_var is set to "yes" in udev's environment.
+</p>
+
+<a name="options"></a>
+<h3>Additional options</h3>
+
+<p>
+Another assignment which can prove useful is the <em>OPTIONS</em> list. A few options are available:
+</p>
+
+<ul>
+<li><b>all_partitions</b> - create all possible partitions for a block device, rather than only those that were initially detected</li>
+<li><b>ignore_device</b> - ignore the event completely</li>
+<li><b>last_rule</b> - ensure that no later rules have any effect</li>
+</ul>
+
+<p>
+For example, the rule below sets the group ownership on my hard disk node, and ensures that no later rule can have any effect:
+</p>
+
+<blockquote><pre>KERNEL=="sda", GROUP="disk", OPTIONS+="last_rule"</pre></blockquote>
+
+
+<h2>Examples</h2>
+
+<a name="example-printer"></a>
+<h3>USB Printer</h3>
+
+<p>
+I power on my printer, and it is assigned device node <em>/dev/lp0</em>. Not satisfied with such a bland name, I decide to use udevinfo to aid me in writing a rule which will provide an alternative name:
+</p>