Update the man page for the new display filter code.

svn path=/trunk/; revision=3113

1 files changed, 23 insertions, 41 deletions

diff --git a/doc/tethereal.pod.template b/doc/tethereal.pod.template
index 6deb5f3eda..34e978dbae 100644
--- a/doc/tethereal.pod.template
+++ b/doc/tethereal.pod.template
@@ -301,53 +301,24 @@ eq, ne, gt, ge, lt, and le.  The IPv4 address is stored in host order,
 so you do not have to worry about how the endianness of an IPv4 address
 when using it in a read filter.
 
-Classless InterDomain Routing (CIDR) notation can be used to test if an
-IPv4 address is in a certain subnet.  For example, this read filter
-will find all packets in the 129.111 Class-B network:
-
-    ip.addr == 129.111.0.0/16
-
-Remember, the number after the slash represents the number of bits used
-to represent the network.  CIDR notation can also be used with
-hostnames, in this example of finding IP addresses on the same Class C
-network as 'sneezy':
-
-    ip.addr eq sneezy/24
-
-The CIDR notation can only be used on IP addresses or hostnames, not in
-variable names.  So, a read filter like "ip.src/24 == ip.dst/24" is
-not valid.  (yet)
-
 IPX networks are represented by unsigned 32-bit integers.  Most likely
 you will be using hexadecimal when testing for IPX network values:
 
     ipx.srcnet == 0xc0a82c00
 
-A substring operator also exists.  You can check the substring
+A slice operator also exists.  You can check the substring
 (byte-string) of any protocol or field.  For example, you can filter on
 the vendor portion of an ethernet address (the first three bytes) like
 this:
 
     eth.src[0:3] == 00:00:83
 
-Or more simply, since the number of bytes is inherent in the byte-string
-you provide, you can provide just the offset.  The previous example can
-be stated like this:
-
-    eth.src[0] == 00:00:83
-
-In fact, the only time you need to explicitly provide a length is when
-you don't provide a byte-string, and are comparing fields against
-fields:
-
-    fddi.src[0:3] == fddi.dst[0:3]
-
-If the length of your byte-string is only one byte, then it must be
-represented in the same way as an unsigned 8-bit integer:
+If the length of your byte-slice is only one byte, then it is still
+represented in hex, but without the preceding "0x": 
 
-    llc[3] == 0xaa
+    llc[3] == aa
 
-You can use the substring operator on a protocol name, too.  And
+You can use the slice operator on a protocol name, too.  And
 remember, the "frame" protocol encompasses the entire packet, allowing
 you to look at the nth byte of a packet regardless of its frame type
 (Ethernet, token-ring, etc.).
@@ -356,16 +327,28 @@ you to look at the nth byte of a packet regardless of its frame type
     ipx[0:2] == ff:ff
     llc[3:1] eq 0xaa
 
-Offsets for byte-strings can also be negative, in which case the
-negative number indicates the number of bytes from the end of the field
-or protocol that you are testing.  Here's how to check the last 4 bytes
-of a frame:
 
-    frame[-4] == 0.1.2.3
+The following syntax governs slices:
+
+	[i:j]	i = start_offset, j = length
+	[i-j]	i = start_offet, j = end_offset, inclusive.
+	[i]	i = start_offset, length = 1
+	[:j]	start_offset = 0, length = j
+	[i:]	start_offset = i, end_offset = end_of_field
 
-or
+
+Offsets and lengths can be negative, in which case they indicate the offset from the
+*end* of the field.  Here's how to check the last 4 bytes of a frame:
 
     frame[-4:4] == 0.1.2.3
+or
+    frame[-4:] == 0.1.2.3
+
+
+You can create complex concatenations of slices using the comma operator:
+
+	field[1,3-5,9:] == 01:03:04:05:09:0a:0b
+
 
 All the above tests can be combined together with logical expressions. 
 These too are expressable in C-like syntax or with English-like
@@ -373,7 +356,6 @@ abbreviations:
 
     and, &&   Logical AND
     or, ||    Logical OR
-    xor, ^^   Logical XOR
     not, !    Logical NOT
 
 Expressions can be grouped by parentheses as well.  The following are