color(7) - Plan 9 from User Space

From 78e51a8c6678b6e3dff3d619aa786669f531f4bc Mon Sep 17 00:00:00 2001 From: rsc Date: Fri, 14 Jan 2005 03:45:44 +0000 Subject: checkpoint --- man/man7/color.html | 169 +++++++++++++++++++++ man/man7/face.html | 127 ++++++++++++++++ man/man7/font.html | 101 +++++++++++++ man/man7/image.html | 175 +++++++++++++++++++++ man/man7/index.html | 76 ++++++++++ man/man7/man.html | 292 +++++++++++++++++++++++++++++++++++ man/man7/map.html | 108 +++++++++++++ man/man7/ms.html | 185 +++++++++++++++++++++++ man/man7/plot.html | 386 +++++++++++++++++++++++++++++++++++++++++++++++ man/man7/plumb.html | 357 +++++++++++++++++++++++++++++++++++++++++++ man/man7/regexp.html | 131 ++++++++++++++++ man/man7/thumbprint.html | 68 +++++++++ man/man7/utf.html | 96 ++++++++++++ 13 files changed, 2271 insertions(+) create mode 100644 man/man7/color.html create mode 100644 man/man7/face.html create mode 100644 man/man7/font.html create mode 100644 man/man7/image.html create mode 100644 man/man7/index.html create mode 100644 man/man7/man.html create mode 100644 man/man7/map.html create mode 100644 man/man7/ms.html create mode 100644 man/man7/plot.html create mode 100644 man/man7/plumb.html create mode 100644 man/man7/regexp.html create mode 100644 man/man7/thumbprint.html create mode 100644 man/man7/utf.html (limited to 'man/man7') diff --git a/man/man7/color.html b/man/man7/color.html new file mode 100644 index 00000000..262e4633 --- /dev/null +++ b/man/man7/color.html @@ -0,0 +1,169 @@ + +color(7) - Plan 9 from User Space + + + + +

COLOR(7) COLOR(7) +

+
+

NAME
+ +
+ + color – representation of pixels and colors
+ +
+

DESCRIPTION
+ +
+ + To address problems of consistency and portability among applications, + Plan 9 uses a fixed color map, called rgbv, on 8-bit-per-pixel + displays. Although this avoids problems caused by multiplexing + color maps between applications, it requires that the color map + chosen be suitable for most purposes and usable for + all. Other systems that use fixed color maps tend to sample the + color cube uniformly, which has advantages--mapping from a (red, + green, blue) triple to the color map and back again is easy--but + ignores an important property of the human visual system: eyes + are much more sensitive to small changes in intensity than + to changes in hue. Sampling the color cube uniformly gives a color + map with many different hues, but only a few shades of each. Continuous + tone images converted into such maps demonstrate conspicuous artifacts. + +
+ + Rather than dice the color cube into subregions of size 6×6×6 (as + in Netscape Navigator) or 8×8×4 (as in previous releases of Plan + 9), picking 1 color in each, the rgbv color map uses a 4×4×4 subdivision, + with 4 shades in each subcube. The idea is to reduce the color + resolution by dicing the color cube into fewer + cells, and to use the extra space to increase the intensity resolution. + This results in 16 grey shades (4 grey subcubes with 4 samples + in each), 13 shades of each primary and secondary color (3 subcubes + with 4 samples plus black) and a reasonable selection of colors + covering the rest of the color cube. The advantage is + better representation of continuous tones. +
+ + The following function computes the 256 3-byte entries in the + color map:
+ +
+ + void + setmaprgbv(uchar cmap[256][3]) + { + + + + uchar *c; + int r, g, b, v; + int num, den; + int i, j; + for(r=0,i=0; r!=4; r++) + for(v=0; v!=4; v++,i+=16) + for(g=0,j=v−r; g!=4; g++) + for(b=0; b!=4; b++,j++){ + c = cmap[i+(j&15)]; + den = r; + if(g > den) + den = g; + if(b > den) + den = b; + if(den == 0) /* would divide check; pick grey shades */ + c[0] = c[1] = c[2] = 17*v; + else{ + num = 17*(4*den+v); + c[0] = r*num/den; + c[1] = g*num/den; + c[2] = b*num/den; + } + } + + + } + + + + +
+ There are 4 nested loops to pick the (red,green,blue) coordinates + of the subcube, and the value (intensity) within the subcube, + indexed by r, g, b, and v, whence the name rgbv. The peculiar + order in which the color map is indexed is designed to distribute + the grey shades uniformly through the map--the i’th grey + shade, 0<=i<=15 has index ix17, with black going to 0 and white to + 255. Therefore, when a call to draw converts a 1, 2 or 4 bit-per-pixel + picture to 8 bits per pixel (which it does by replicating the + pixels’ bits), the converted pixel values are the appropriate + grey shades. +
+ + The rgbv map is not gamma-corrected, for two reasons. First, photographic + film and television are both normally under-corrected, the former + by an accident of physics and the latter by NTSC’s design. Second, + we require extra color resolution at low intensities because of + the non-linear response and adaptation of + the human visual system. Properly gamma-corrected displays with + adequate low-intensity resolution pack the high-intensity parts + of the color cube with colors whose differences are almost imperceptible. + Either reason suggests concentrating the available intensities + at the low end of the range. +
+ + On ‘true-color’ displays with separate values for the red, green, + and blue components of a pixel, the values are chosen so 0 represents + no intensity (black) and the maximum value (255 for an 8-bit-per-color + display) represents full intensity (e.g., full red). Common display + depths are 24 bits per pixel, with 8 bits per + color in order red, green, blue, and 16 bits per pixel, with 5 + bits of red, 6 bits of green, and 5 bits of blue. +
+ + Colors may also be created with an opacity factor called alpha, + which is scaled so 0 represents fully transparent and 255 represents + opaque color. The alpha is premultiplied into the other channels, + as described in the paper by Porter and Duff cited in draw(3). + The function setalpha (see allocimage(3)) aids the + initialization of color values with non-trivial alpha. +
+ + The packing of pixels into bytes and words is odd. For compatibility + with VGA frame buffers, the bits within a pixel byte are in big-endian + order (leftmost pixel is most significant bits in byte), while + bytes within a pixel are packed in little-endian order. Pixels + are stored in contiguous bytes. This results in unintuitive + pixel formats. For example, for the RGB24 format, the byte ordering + is blue, green, red. +
+ + To maintain a constant external representation, the draw(3) interface + as well as the various graphics libraries represent colors by + 32-bit numbers, as described in color(3).
+ +
+

SEE ALSO
+ +
+ + color(3), graphics(3), draw(3)
+ +
+ +

+ + +

		+
	+ + + +

+ + diff --git a/man/man7/face.html b/man/man7/face.html new file mode 100644 index 00000000..db220326 --- /dev/null +++ b/man/man7/face.html @@ -0,0 +1,127 @@ + +face(7) - Plan 9 from User Space + + + + +

FACE(7) FACE(7) +

+
+

NAME
+ +
+ + face – face files
+ +
+

DESCRIPTION
+ +
+ + The directories /usr/$user/lib/face and /lib/face contain a hierarchy + of images of people. In those directories are subdirectories named + by the sizes of the corresponding image files: 48x48x1 (48 by + 48 pixels, one bit per pixel); 48x48x2 (48 by 48 pixels, two (grey) + bits per pixel); 48x48x4 (48 by 48 + pixels, four (grey) bits per pixel); 48x48x8 (48 by 48 pixels, + eight (color-mapped) bits per pixel); 512x512x8 (512 by 512 pixels, + eight (color-mapped) bits per pixel); 512x512x24 (512 by 512 pixels, + twenty-four bits per pixel (3 times 8 bits per color)). The large + files serve no special purpose; they are stored as + images (see image(7)). The small files are the ‘icons’ displayed + by faces and seemail (see Plan 9’s faces(1)); for depths less + than 4, their format is special. +
+ + One- and two-bit deep icons are stored as text, one line of the + file to one scan line of display. Each line is divided into 8-bit, + 16-bit, or 32-bit big-endian words, stored as a list of comma-separated + hexadecimal C constants, such as:
+ +
+ + 0x9200, 0x1bb0, 0x003e, + + + + +
+ This odd format is historical and the programs that read it are + somewhat forgiving about blanks and the need for commas. +
+ + The files lib/face/*/.dict hold a correspondence between users + at machines and face files. The format is
+ +
+ + machine/user directory/file.ver
+ +
+ + +
+ The machine is the domain name of the machine sending the message, + and user the name of the user sending it. The directory is a further + subdirectory of (say) /lib/face/48x48x1, named by a single letter + corresponding to the first character of the user names. The file + is the name of the file, typically but not + always the user name, and ver is a number to distinguish different + images, for example to distinguish the image for Bill Gates from + the image for Bill Joy, both of which might otherwise be called + b/bill. For example, Bill Gates might be represented by the line
+ +
+ + microsoft.com/bill b/bill.1 + + + + +
+ If multiple entries exist for a user in the various .dict files, + faces chooses the highest pixel size less than or equal to that + of the display on which it is running. +
+ + Finally, or rather firstly, the file /lib/face/.machinelist contains + a list of machine/domain pairs, one per line, to map any of a + set of machines to a single domain name to be looked up in the + .dict files. The machine name may be a regular expression, so + for example the entry
+ +
+ + .*research\.bell−labs\.com astro + + + + +
+ maps any of the machines in Bell Labs Research into the shorthand + name astro, which then appears as a domain name in the .dict files.
+ +
+

SEE ALSO
+ +
+ + mail(1), tweak(1), image(7)
+ +
+ +

+ + +

		+
	+ + + +

+ + diff --git a/man/man7/font.html b/man/man7/font.html new file mode 100644 index 00000000..a6bd6a91 --- /dev/null +++ b/man/man7/font.html @@ -0,0 +1,101 @@ + +font(7) - Plan 9 from User Space + + + + +

FONT(7) FONT(7) +

+
+

NAME
+ +
+ + font, subfont – external format for fonts and subfonts
+ +
+

SYNOPSIS
+ +
+ + #include <draw.h> + +
+

DESCRIPTION
+ +
+ + Fonts and subfonts are described in cachechars(3). +
+ + External fonts are described by a plain text file that can be + read using openfont. The format of the file is a header followed + by any number of subfont range specifications. The header contains + two numbers: the height and the ascent, both in pixels. The height + is the inter-line spacing and the ascent is the distance from + the top of the line to the baseline. These numbers are chosen + to display consistently all the subfonts of the font. A subfont + range specification contains two or three numbers and a file name. + The numbers are the inclusive range of characters covered by the + subfont, with an optional starting position within the subfont, + and the file name names an external file suitable for readsubfont + (see graphics(3)). The minimum number of a covered range is mapped + to the specified starting position (default zero) of the corresponding + subfont. If the subfont file name does not begin with a slash, + it is taken relative to the directory containing the + font file. Each field must be followed by some white space. Each + numeric field may be C-format decimal, octal, or hexadecimal. + +
+ + External subfonts are represented in a more rigid format that + can be read and written using readsubfont and writesubfont (see + subfont(3)). The format for subfont files is: an image containing + character glyphs, followed by a subfont header, followed by character + information. The image has the format for external image + files described in image(7). The subfont header has 3 decimal + strings: n, height, and ascent. Each number is right-justified + and blank padded in 11 characters, followed by a blank. The character + info consists of n+1 6-byte entries, each giving the Fontchar + x (2 bytes, low order byte first), top, bottom, + left, and width. The x field of the last Fontchar is used to calculate + the image width of the previous character; the other fields in + the last Fontchar are irrelevant. +
+ + Note that the convention of using the character with value zero + (NUL) to represent characters of zero width (see draw(3)) means + that fonts should have, as their zeroth character, one with non-zero + width.
+ +
+

FILES
+ +
+ + /usr/local/plan9/font/* font directories
+ +
+

SEE ALSO
+ +
+ + graphics(3), draw(3), cachechars(3), subfont(3)
+ +
+ +

+ + +

		+
	+ + + +

+ + diff --git a/man/man7/image.html b/man/man7/image.html new file mode 100644 index 00000000..f81c023b --- /dev/null +++ b/man/man7/image.html @@ -0,0 +1,175 @@ + +image(7) - Plan 9 from User Space + + + + +

IMAGE(7) IMAGE(7) +

+
+

NAME
+ +
+ + image – external format for images
+ +
+

SYNOPSIS
+ +
+ + #include <draw.h> + +
+

DESCRIPTION
+ +
+ + Images are described in graphics(3), and the definition of pixel + values is in color(7). Fonts and images are stored in external + files in machine-independent formats. +
+ + Image files are read and written using readimage and writeimage + (see allocimage(3)),or readmemimage and writememimage (see memdraw(3)). + An uncompressed image file starts with 5 strings: chan, r.min.x, + r.min.y, r.max.x, and r.max.y. Each is right-justified and blank + padded in 11 + characters, followed by a blank. The chan value is a textual string + describing the pixel format (see strtochan in graphics(3) and + the discussion of channel descriptors below), and the rectangle + coordinates are decimal strings. The rest of the file contains + the r.max.y−r.min.y rows of pixel data. A row consists + of the byte containing pixel r.min.x and all the bytes up to and + including the byte containing pixel r.max.x-1. For images with + depth d less than eight, a pixel with x-coordinate = x will appear + as d contiguous bits in a byte, with the pixel’s high order bit + starting at the byte’s bit number w×(x mod (8/w)), where + bits within a byte are numbered 0 to 7 from the high order to + the low order bit. Rows contain integral number of bytes, so there + may be some unused pixels at either end of a row. If d is greater + than 8, the definition of images requires that it will a multiple + of 8, so pixel values take up an integral number of bytes. +
+ + The loadimage and unloadimage functions described in allocimage(3) + also deal with rows in this format, stored in user memory. +
+ + The channel format string is a sequence of two-character channel + descriptions, each comprising a letter (r for red, g for green, + b for blue, a for alpha, m for color-mapped, k for greyscale, + and x for “don’t care”) followed by a number of bits per pixel. + The sum of the channel bits per pixel is the depth of the image, + which must be either a divisor or a multiple of eight. It is an + error to have more than one of any channel but x. An image must + have either a greyscale channel; a color mapped channel; or red, + green, and blue channels. If the alpha channel is present, it + must be at least as deep as any other channel. +
+ + The channel string defines the format of the pixels in the file, + and should not be confused with ordering of bytes in the file. + In particular 'r8g8b8' pixels have byte ordering blue, green, + and red within the file. See color(7) for more details of the + pixel format. +
+ + A venerable yet deprecated format replaces the channel string + with a decimal ldepth, which is the base two logarithm of the + number of bits per pixel in the image. In this case, ldepths 0, + 1, 2, and 3 correspond to channel descriptors k1, k2, k4, and + m8, respectively. +
+ + Compressed image files start with a line of text containing the + word compressed, followed by a header as described above, followed + by the image data. The data, when uncompressed, is laid out in + the usual form. +
+ + The data is represented by a string of compression blocks, each + encoding a number of rows of the image’s pixel data. Compression + blocks are at most 6024 bytes long, so that they fit comfortably + in a single 9P message. Since a compression block must encode + a whole number of rows, there is a limit (about 5825 + bytes) to the width of images that may be encoded. Most wide images + are in subfonts, which, at 1 bit per pixel (the usual case for + fonts), can be 46600 pixels wide. +
+ + A compression block begins with two decimal strings of twelve + bytes each. The first number is one more than the y coordinate + of the last row in the block. The second is the number of bytes + of compressed data in the block, not including the two decimal + strings. This number must not be larger than 6000. +
+ + Pixels are encoded using a version of Lempel & Ziv’s sliding window + scheme LZ77, best described in J A Storer & T G Szymanski ‘Data + Compression via Textual Substitution’, JACM 29#4, pp. 928-951. + +
+ + The compression block is a string of variable-length code words + encoding substrings of the pixel data. A code word either gives + the substring directly or indicates that it is a copy of data + occurring previously in the pixel stream. +
+ + In a code word whose first byte has the high-order bit set, the + rest of the byte indicates the length of a substring encoded directly. + Values from 0 to 127 encode lengths from 1 to 128 bytes. Subsequent + bytes are the literal pixel data. +
+ + If the high-order bit is zero, the next 5 bits encode the length + of a substring copied from previous pixels. Values from 0 to 31 + encode lengths from 3 to 34 bytes. The bottom two bits of the + first byte and the 8 bits of the next byte encode an offset backward + from the current position in the pixel data at which the copy + is to be found. Values from 0 to 1023 encode offsets from 1 to + 1024. The encoding may be ‘prescient’, with the length larger + than the offset, which works just fine: the new data is identical + to the data at the given offset, even though the two strings overlap. + +
+ + Some small images, in particular 48×48 face files as used by seemail + (see Plan 9’s faces(1) and face(7)) and 16×16 cursors, can be stored + textually, suitable for inclusion in C source. Each line of text + represents one scan line as a comma-separated sequence of hexadecimal + bytes, shorts, or words in C format. For + cursors, each line defines a pair of bytes. (It takes two images + to define a cursor; each must be stored separately to be processed + by programs such as tweak(1).) Face files of one bit per pixel + are stored as a sequence of shorts, those of larger pixel sizes + as a sequence of longs. Software that reads these files must + deduce the image size from the input; there is no header. These + formats reflect history rather than design.
+ +
+

SEE ALSO
+ +
+ + jpg(1), tweak(1), graphics(3), draw(3), allocimage(3), color(7), + face(7), font(7)
+ +
+ +

+ + +

		+
	+ + + +

+ + diff --git a/man/man7/index.html b/man/man7/index.html new file mode 100644 index 00000000..5f61f6e5 --- /dev/null +++ b/man/man7/index.html @@ -0,0 +1,76 @@ + + +Manual Section 7 - Plan 9 from User Space + + + +

+ + +

	+
+ + Manual Section 7 - Plan 9 from User Space + +
+
+
+
+
color(7)	color – representation of pixels and colors +
+
+
+
face(7)	face – face files +
+
+
+
font(7)	font, subfont – external format for fonts and subfonts +
+
+
+
image(7)	image – external format for images +
+
+
+
man(7)	man – macros to typeset manual +
+
+
+
map(7)	map – digitized map formats +
+
+
+
ms(7)	ms – macros for formatting manuscripts +
+
+
+
plot(7)	plot – graphics interface +
+
+
+
plumb(7)	plumb – format of plumb messages and rules +
+
+
+
regexp(7)	regexp – Plan 9 regular expression notation +
+
+
+
thumbprint(7)	thumbprint – public key thumbprints +
+
+
+
utf(7)	UTF, Unicode, ASCII, rune – character set and format +

+ + +

		+
	+ + + +

+ + diff --git a/man/man7/man.html b/man/man7/man.html new file mode 100644 index 00000000..4087e795 --- /dev/null +++ b/man/man7/man.html @@ -0,0 +1,292 @@ + +man(7) - Plan 9 from User Space + + + + +

MAN(7) MAN(7) +

+
+

NAME
+ +
+ + man – macros to typeset manual
+ +
+

SYNOPSIS
+ +
+ + nroff −man file ... +
+ + troff −man file ...
+ +
+

DESCRIPTION
+ +
+ + These macros are used to format pages of this manual. +
+ + Except in .LR and .RL requests, any text argument denoted t in + the request summary may be zero to six words. Quotes " ... " may + be used to include blanks in a ‘word’. If t is empty, the special + treatment is applied to the next text input line (the next line + that doesn’t begin with dot). In this way, for example, .I +may be used to italicize a line of more than 6 words, or .SM followed + by .B to make small letters in ‘bold’ font. +
+ + A prevailing indent distance is remembered between successive + indented paragraphs, and is reset to default value upon reaching + a non-indented paragraph. Default units for indents i are ens. + +
+ + The fonts are
+ R     roman, the main font, preferred for diagnostics
+ I     italic, preferred for parameters, short names of commands, names + of manual pages, and naked function names
+ B     ‘bold’, actually the constant width font, preferred for examples, + file names, declarations, keywords, names of struct members, and + literals (numbers are rarely literals)
+ L     also the constant width font. In troff L=B; in nroff arguments + of the macros .L, .LR, and .RL are printed in quotes; preferred + only where quotes really help (e.g. lower-case literals and punctuation). + +
+ + Type font and size are reset to default values before each paragraph, + and after processing font- or size-setting macros. +
+ + The −man macros admit equations and tables in the style of eqn(1) + and tbl(1), but do not support arguments on .EQ and .TS macros. + +
+ + These strings are predefined by −man:
+ \*R   ‘®’, ‘(Reg)’ in nroff.
+ \*S   Change to default type size. \*9 The root directory of the + Plan 9 installation.
+ +
+

FILES
+ +
+ + /usr/local/plan9/tmac/tmac.an + + + /usr/local/plan9/tmac/tmac.antimes + +
+

SEE ALSO
+ +
+ + troff(1), man(1)
+ +
+

REQUESTS
+Request Cause If no      Explanation
+ +
+ + +
+ + Break Argument
+ +
+ +
+.B t     no +
+ + + + + + +t=n.t.l.*    Text t is ‘bold’.
+.BI t    no +
+ + + + + + +t=n.t.l.    Join words of t alternating bold and italic.
+.BR t    no +
+ + + + + + +t=n.t.l.    Join words of t alternating bold and Roman.
+.DT      no           Restore default tabs.
+.EE      yes           End displayed example
+.EX      yes           Begin displayed example
+.HP i    yes +
+ + + + +i=p.i.*     Set prevailing indent to i. Begin paragraph with hanging +indent.
+.I t     no +
+ + + + + + +t=n.t.l.    Text t is italic.
+.IB t    no +
+ + + + + + +t=n.t.l.    Join words of t alternating italic and bold.
+.IP x i yes +
+ + + + +x=""      Same as .TP with tag x.
+.IR t    no +
+ + + + + + +t=n.t.l.    Join words of t alternating italic and Roman.
+.L t     no +
+ + + + + + +t=n.t.l.    Text t is literal.
+.LP      yes           Same as .PP.
+.LR t    no           Join 2 words of t alternating literal and Roman.
+.PD d    no +
+ + + + + + +d=.4v    Interparagraph distance is d.
+.PP      yes           Begin paragraph. Set prevailing indent to default.
+.RE      yes           End of relative indent. Set prevailing indent to amount +of starting .RS.
+.RI t    no +
+ + + + + + +t=n.t.l.    Join words of t alternating Roman and italic.
+.RL t    no           Join 2 or 3 words of t alternating Roman and literal.
+.RS i    yes +
+ + + + +i=p.i.     Start relative indent, move left margin in distance i. +Set prevailing indent to default for nested indents.
+.SH t    yes +
+ + + + +t=""      Subhead; reset paragraph distance.
+.SM t    no +
+ + + + + + +t=n.t.l.    Text t is small.
+.SS t    no +
+ + + + + + +t=""      Secondary subhead.
+.TF s    yes           Prevailing indent is wide as string s in font L; paragraph +distance is 0.
+.TH n c x      yes       Begin page named n of chapter c; x is extra commentary, +e.g. ‘local’, for page head. Set prevailing indent and tabs to +default.
+.TP i    yes +
+ + + + +i=p.i.     Set prevailing indent to i. Restore default indent if +i=0. Begin indented paragraph with hanging tag given by next text +line. If tag doesn’t fit, place it on separate line.
+.1C      yes           Equalize columns and return to 1-column output
+.2C      yes           Start 2-column nofill output +
+ +* n.t.l. = next text line; p.i. = prevailing indent
+

BUGS
+ +
+ + There’s no way to fool troff into handling literal double quote + marks " in font-alternation macros, such as .BI. +
+ + There is no direct way to suppress column widows in 2-column output; + the column lengths may be adjusted by inserting .sp requests before + the closing .1C.
+ +
+ +

+ + +

		+
	+ + + +

+ + diff --git a/man/man7/map.html b/man/man7/map.html new file mode 100644 index 00000000..1ebdfbba --- /dev/null +++ b/man/man7/map.html @@ -0,0 +1,108 @@ + +map(7) - Plan 9 from User Space + + + + +

MAP(7) MAP(7) +

+
+

NAME
+ +
+ + map – digitized map formats
+ +
+

DESCRIPTION
+ +
+ + Files used by map(7) are a sequence of structures of the form: + +
+ + struct { + + + + signed char patchlatitude; + signed char patchlongitude; + short n; + union { + + + + struct { + short latitude; + short longitude; + } point[n]; + struct { + short latitude; + short longitude; + struct { + signed char latdiff; + signed char londiff; + } point[–n]; + } highres; + + + } segment; + + + }; +where short stands for 16-bit integers and there is no padding + within or between structs. Shorts are stored in little-endian + order, low byte first. To assure portability, map accesses them + bytewise. +
+ + Fields patchlatitude and patchlongitude tell to what 10-degree + by 10-degree patch of the earth’s surface a segment belongs. Their + values range from –9 to 8 and from –18 to 17, respectively, and + indicate the coordinates of the southeast corner of the patch + in units of 10 degrees. +
+ + Each segment of |n| points is connected; consecutive segments + are not necessarily related. Latitude and longitude are measured + in units of 0.0001 radian. If n is negative, then differences + to the first and succeeding points are measured in units of 0.00001 + radian. Latitude is counted positive to the north and longitude + positive to the west. +
+ + The patches are ordered lexicographically by patchlatitude then + patchlongitude. A printable index to the first segment of each + patch in a file named data is kept in an associated file named + data.x. Each line of an index file contains patchlatitude, patchlongitude + and the byte position of the + patch in the map file. Both the map file and the index file are + ordered by patch latitude and longitude.
+ +
+

SEE ALSO
+ +
+ + map(7)
+ The data comes from the World Data Bank I and II and U.S. Government + sources: the Census Bureau, Geological Survey, and CIA.
+ +
+ +

+ + +

		+
	+ + + +

+ + diff --git a/man/man7/ms.html b/man/man7/ms.html new file mode 100644 index 00000000..3ef5ef5d --- /dev/null +++ b/man/man7/ms.html @@ -0,0 +1,185 @@ + +ms(7) - Plan 9 from User Space + + + + +

MS(7) MS(7) +

+
+

NAME
+ +
+ + ms – macros for formatting manuscripts
+ +
+

SYNOPSIS
+ +
+ + nroff −ms [ options ] file ...
+ troff −ms [ options ] file ...
+ +
+

DESCRIPTION
+ +
+ + This package of nroff and troff(1) macro definitions provides + a canned formatting facility for technical papers in various formats. + +
+ + The macro requests are defined below. Many nroff and troff requests + are unsafe in conjunction with this package, but the following + requests may be used with impunity after the first .PP: .bp, .br, + .sp, .ls, .na. +
+ + Output of the eqn(1), tbl(1), pic(1) and grap(1) preprocessors + for equations, tables, pictures, and graphs is acceptable as input.
+ +
+

FILES
+ +
+ + /usr/local/plan9/tmac/tmac.s + +
+

SEE ALSO
+ +
+ + M. E. Lesk, “Typing Documents on the UNIX System: Using the –ms + Macros with Troff and Nroff”, Unix Research System Programmer’s + Manual, Tenth Edition, Volume 2.
+ eqn(1), troff(1), tbl(1), pic(1)
+ +
+

REQUESTS
+Request Initial Cause Explanation
+ +
+ + +
+ + Value Break
+ +
+ +
+.1C      yes    yes    One column format on a new page.
+.2C      no    yes    Two column format.
+.AB      no    yes    Begin abstract.
+.AE      -     yes    End abstract.
+.AI      no    yes    Author’s institution follows. Suppressed in .TM.
+.AT      no    yes    Print ‘Attached’ and turn off line filling.
+.AU x y no    yes    Author’s name follows. x is location and y is extension, +ignored except in TM.
+.B x y    no    no     Print x in boldface, append y; if no argument switch +to boldface.
+.B1      no    yes    Begin text to be enclosed in a box.
+.B2      no    yes    End boxed text.
+.BI x y no    no     Print x in bold italic and append y; if no argument +switch to bold italic.
+.BT      date no     Bottom title, automatically invoked at foot of page. +May be redefined.
+.BX x     no    no     Print x in a box.
+.CW x y no    no     Constant width font for x, append y; if no argument +switch to constant width.
+.CT      no    yes    Print ‘Copies to’ and turn off line filling.
+.DA x     nroff no     ‘Date line’ at bottom of page is x. Default is +today.
+.DE      -     yes    End displayed text. Implies .KE.
+.DS x     no    yes    Start of displayed text, to appear verbatim line-by-line: +I indented (default), L left-justified, C centered, B (block) +centered with straight left margin. Implies .KS.
+.EG      no    -      Print document in BTL format for ‘Engineer’s Notes.’ +Must be first.
+.EN      -     yes    Space after equation produced by neqn or eqn(1).
+.EQ x y -     yes    Display equation. Equation number is y. Optional +x is I, L, C as in .DS.
+.FE      -     yes    End footnote.
+.FP x     -     no     Set font positions for a family, e.g., .FP lucidasans +.FS     no    no     Start footnote. The note will be moved to the bottom +of the page.
+.HO      -     no     ‘Bell Laboratories, Holmdel, New Jersey 07733’.
+.I x y    no    no     Italicize x, append y; if no argument switch to italic.
+.IH      no    no     ‘Bell Laboratories, Naperville, Illinois 60540’
+.IM      no    no     Print document in BTL format for an internal memorandum. +Must be first.
+.IP x y no    yes    Start indented paragraph, with hanging tag x. Indentation +is y ens (default 5).
+.KE      -     yes    End keep. Put kept text on next page if not enough room.
+.KF      no    yes    Start floating keep. If the kept text must be moved +to the next page, float later text back to this page.
+.KS      no    yes    Start keeping following text.
+.LG      no    no     Make letters larger.
+.LP      yes    yes    Start left-blocked paragraph.
+.LT      no    yes    Start a letter; a non-empty first argument produces +a full Lucent letterhead, a second argument is a room number, +a third argument is a telephone number.
+.MF      -     -      Print document in BTL format for ‘Memorandum for File.’ +Must be first.
+.MH      -     no     ‘Bell Laboratories, Murray Hill, New Jersey 07974’.
+.MR      -     -      Print document in BTL format for ‘Memorandum for Record.’ +Must be first.
+.ND date troff no     Use date supplied (if any) only in special BTL +format positions; omit from page footer.
+.NH n     -     yes    Same as .SH, with automatic section numbers like ‘1.2.3’; +n is subsection level (default 1).
+.NL      yes    no     Make letters normal size.
+.P1      -     yes    Begin program display in constant width font.
+.P2      -     yes    End program display.
+.PE      -     yes    End picture; see pic(1).
+.PF      -     yes    End picture; restore vertical position.
+.PP      no    yes    Begin paragraph. First line indented.
+.PS h w -     yes    Start picture; height and width in inches.
+.PY      -     no     ‘Bell Laboratories, Piscataway, New Jersey 08854’
+.QE      -     yes    End quoted material.
+.QP      -     yes    Begin quoted paragraph (indent both margins).
+.QS      -     yes    Begin quoted material (indent both margins).
+.R       yes    no     Roman text follows.
+.RE      -     yes    End relative indent level.
+.RP      no    -      Cover sheet and first page for released paper. Must precede +other requests.
+.RS      -     yes    Start level of relative indentation from which subsequent +indentation is measured.
+.SG x     no    yes    Insert signature(s) of author(s), ignored except +in .TM and .LT. x is the reference line (initials of author and +typist). .}f
+.SH      -     yes    Section head follows, font automatically bold.
+.SM      no    no     Make letters smaller.
+.TA x... 5...    no     Set tabs in ens. Default is 5 10 15 ...
+.TE      -     yes    End table; see tbl(1).
+.TH      -     yes    End heading section of table.
+.TL      no    yes    Title follows.
+.TM x... no    -      Print document in BTL technical memorandum format. +Arguments are TM number, (quoted list of) case number(s), and +file number. Must precede other requests.
+.TR x     -     -      Print in BTL technical report format; report number +is x. Must be first.
+.TS x     -     yes    Begin table; if x is H table heading is repeated on +new pages.
+.UL x     -     no     Underline argument (even in troff).
+.UX y z -     no     ‘zUNIXy’; first use gives registered trademark notice.
+.WH      -     no     ‘Bell Laboratories, Whippany, New Jersey 07981’.
+ +

+ + +

		+
	+ + + +

+ + diff --git a/man/man7/plot.html b/man/man7/plot.html new file mode 100644 index 00000000..ca64b3fd --- /dev/null +++ b/man/man7/plot.html @@ -0,0 +1,386 @@ + +plot(7) - Plan 9 from User Space + + + + +

PLOT(7) PLOT(7) +

+
+

NAME
+ +
+ + plot – graphics interface
+ +
+

DESCRIPTION
+ +
+ + Files of this format are interpreted by plot(1) to draw graphics + on the screen. A plot file is a UTF stream of instruction lines. + Arguments are delimited by spaces, tabs, or commas. Numbers may + be floating point. Punctuation marks (except :) , spaces, and + tabs at the beginning of lines are ignored. Comments run from + : to newline. Extra letters appended to a valid instruction are + ignored. Thus ...line, line, li all mean the same thing. Arguments + are interpreted as follows:
+ 1.    If an instruction requires no arguments, the rest of the line + is ignored.
+ 2.    If it requires a string argument, then all the line after the + first field separator is passed as argument. Quote marks may be + used to preserve leading blanks. Strings may include newlines + represented as \n.
+ 3.    Between numeric arguments alphabetic characters and punctuation + marks are ignored. Thus line from 5 6 to 7 8 draws a line from + (5, 6) to (7, 8).
+ 4.    Instructions with numeric arguments remain in effect until a + new instruction is read. Such commands may spill over many lines. + Thus the following sequence will draw a polygon with vertices + (4.5, 6.77), (5.8, 5.6), (7.8, 4.55), and (10.0, 3.6).
+ +
+ + move 4.5 6.77 + vec 5.8, 5.6 7.8 + 4.55 10.0, 3.6 4.5, 6.77 + + + + +
+ The instructions are executed in order. The last designated point + in a line, move, rmove, vec, rvec, arc, or point command becomes + the ‘current point’ (X,Y) for the next command.
+
Open & Close
+ o string   Open plotting device. For troff, string specifies the + size of the plot (default is 6i).
+ cl      Close plotting device.
+
Basic Plotting Commands
+ e       Start another frame of output.
+ m x y    (move) Current point becomes x y.
+ rm dx dyCurrent point becomes X+dx Y+dy.
+ poi x yPlot the point x y and make it the current point.
+ v x y    Draw a vector from the current point to x y.
+ rv dx dyDraw vector from current point to X+dx Y+dy
+ li x1 y1 x2 y2
+ +
+ + +
+ + Draw a line from x1 y1 to x2 y2. Make the current point x2 y2.
+ +
+ +
+ t string   Place the string so that its first character is centered + on the current point (default). If string begins with \C (\R), + it is centered (right-adjusted) on the current point. A backslash + at the beginning of the string may be escaped with another backslash.
+ a x1 y1 x2 y2 xc yc r
+ +
+ + +
+ + Draw a circular arc from x1 y1 to x2 y2 with center xc yc and + radius r. If the radius is positive, the arc is drawn counterclockwise; + negative, clockwise. The starting point is exact but the ending + point is approximate.
+ +
+ +
+ ci xc yc r
+ +
+ + +
+ + Draw a circle centered at xc yc with radius r. If the range and + frame parameters do not specify a square, the ‘circle’ will be + elliptical.
+ +
+ +
+ di xc yc r
+ +
+ + +
+ + Draw a disc centered at xc yc with radius r using the filling + color (see cfill below).
+ +
+ +
+ bo x1 y1 x2 y2
+ +
+ + +
+ + Draw a box with lower left corner at x1 y1 and upper right corner + at x2 y2.
+ +
+ +
+ sb x1 y1 x2 y2
+ +
+ + +
+ + Draw a solid box with lower left corner at x1 y1 and upper right + corner at x2 y2 using the filling color (see cfill below).
+ +
+ +
+ par x1 y1 x2 y2 xg yg
+ +
+ + +
+ + Draw a parabola from x1 y1 to x2 y2 ‘guided’ by xg yg. The parabola + passes through the midpoint of the line joining xg yg with the + midpoint of the line joining x1 y1 and x2 y2 and is tangent to + the lines from xg yg to the endpoints.
+ +
+ +
+ pol { {x1 y1 ... xn yn} ... {X1 Y1 ... Xm Ym} } + +
+ + +
+ + Draw polygons with vertices x1 y1 ... xn yn and X1 Y1 ... Xm Ym. + If only one polygon is specified, the inner brackets are not needed.
+ +
+ +
+ fi { {x1 y1 ... xn yn} ... {X1 Y1 ... Xm Ym} } + +
+ + +
+ + Fill a polygon. The arguments are the same as those for pol except + that the first vertex is automatically repeated to close each + polygon. The polygons do not have to be connected. Enclosed polygons + appear as holes.
+ +
+ +
+ sp { {x1 y1 ... xn yn} ... {X1 Y1 ... Xm Ym} } + +
+ + +
+ + Draw a parabolic spline guided by x1 y1 ... xn yn with simple + endpoints.
+ +
+ +
+ fsp { {x1 y1 ... xn yn} ... {X1 Y1 ... Xm Ym} } + +
+ + +
+ + Draw a parabolic spline guided by x1 y1 ... xn yn with double + first endpoint.
+ +
+ +
+ lsp { {x1 y1 ... xn yn} ... {X1 Y1 ... Xm Ym} } + +
+ + +
+ + Draw a parabolic spline guided by x1 y1 ... xn yn with double + last endpoint.
+ +
+ +
+ dsp { {x1 y1 ... xn yn} ... {X1 Y1 ... Xm Ym} } + +
+ + +
+ + Draw a parabolic spline guided by x1 y1 ... xn yn with double + endpoints.
+ +
+ +
+ csp { {x1 y1 ... xn yn} ... {X1 Y1 ... Xm Ym} } + in filename
+ +
+ + +
+ + (include) Take commands from filename.
+ +
+ +
+ de string { commands } + +
+ + +
+ + Define string as commands.
+ +
+ +
+ ca string scale
+ +
+ + +
+ + Invoke commands defined as string applying scale to all coordinates.
+ +
+ +
+
Commands Controlling the Environment
+ co string
+ +
+ + +
+ + Use color given by first character of string, one of red, yellow, + green, blue, cyan, magenta, white, and kblack. If string begins + with a digit, it is taken to be a 32-bit number specifying 8 bit + each of red, green, blue, and alpha. For example, 0xFFFF00FF denotes + solid yellow. + +
+ +
+ pe string
+ +
+ + +
+ + Use string as the style for drawing lines. The available pen styles + are: solid, dott[ed], short, long, dotd[ashed], cdash, ddash + +
+ +
+ cf string
+ +
+ + +
+ + Color for filling (see co, above).
+ +
+ +
+ ra x1 y1 x2 y2
+ +
+ + +
+ + The data will fall between x1 y1 and x2 y2. The plot will be magnified + or reduced to fit the device as closely as possible.
+ Range settings that exactly fill the plotting area with unity + scaling appear below for devices supported by the filters of plot(1). + The upper limit is just outside the plotting area. In every case + the plotting area is taken to be square; points outside may be + displayable on devices with nonsquare faces. + +
+ +
+ fr px1 py1 px2 py2
+ +
+ + +
+ + Plot the data in the fraction of the display specified by px1 + py1 for lower left corner and px2 py2 for upper right corner. + Thus frame .5 0 1. .5 plots in the lower right quadrant of the + display; frame 0. 1. 1. 0. uses the whole display but inverts + the y coordinates.
+ +
+ +
+ sa      Save the current environment, and move to a new one. The new + environment inherits the old one. There are 7 levels.
+ re      Restore previous environment.
+ +
+

SEE ALSO
+ +
+ + plot(1), graph(1)
+ +
+ +

+ + +

		+
	+ + + +

+ + diff --git a/man/man7/plumb.html b/man/man7/plumb.html new file mode 100644 index 00000000..eca67a76 --- /dev/null +++ b/man/man7/plumb.html @@ -0,0 +1,357 @@ + +plumb(7) - Plan 9 from User Space + + + + +

PLUMB(7) PLUMB(7) +

+
+

NAME
+ +
+ + plumb – format of plumb messages and rules
+ +
+

SYNOPSIS
+ +
+ + #include <plumb.h> + +
+

DESCRIPTION
+ +
+ +
Message format
+ The messages formed by the plumb(3) library are formatted for + transmission between processes into textual form, using newlines + to separate the fields. Only the data field may contain embedded + newlines. The fields occur in a specified order, and each has + a name, corresponding to the elements of the Plumbmsg +structure, that is used in the plumbing rules. The fields, in + order, are:
+ +
+ + src     application/service generating message
+ dst     destination ‘port’ for message
+ wdir    working directory (used if data is a file name)
+ type    form of the data, e.g. text + attr    attributes of the message, in name=value pairs separated by + white space (the value must follow the usual quoting convention + if it contains white space or quote characters or equal signs; + it cannot contain a newline)
+ ndata   number of bytes of data
+ data    the data itself
+ +
+ At the moment, only textual data (type=text) is supported. +
+ + All fields are optional, but type should usually be set since + it describes the form of the data, and ndata must be an accurate + count (possibly zero) of the number of bytes of data. A missing + field is represented by an empty line.
+
Plumbing rules
+ The plumber (see plumb(1)) receives messages on its send port + (applications send messages there), interprets and reformats them, + and (typically) emits them from a destination port. Its behavior + is determined by a plumbing rules file, default /usr/$user/lib/plumbing, + which defines a set of pattern/action + rules with which to analyze, rewrite, and dispatch received messages. + +
+ + The file is a sequence of rule sets, each of which is a set of + one-line rules called patterns and actions. There must be at least + one pattern and one action in each rule set. (The only exception + is that a rule set may contain nothing but plumb to rules; such + a rule set declares the named ports but has no other effect.) + A + blank line terminates a rule set. Lines beginning with a # character + are commentary and are regarded as blank lines. +
+ + A line of the form
+ +
+ + include file
+ +
+ substitutes the contents of file for the line, much as in a C + #include statement. Unlike in C, the file name is not quoted. + If file is not an absolute path name, or one beginning ./ or ../, + file is looked for first in the directory in which the plumber + is executing, and then in /sys/lib/plumb. +
+ + When a message is received by the plumber, the rule sets are examined + in order. For each rule set, if the message matches all the patterns + in the rule set, the actions associated with the rule set are + triggered to dispose of the message. If a rule set is triggered, + the rest are ignored for this message. If none is + triggered, the message is discarded (giving a write error to the + sender) unless it has a dst field that specifies an existing port, + in which case the message is emitted, unchanged, from there. +
+ + Patterns and actions all consist of three components: an object, + a verb, and arguments. These are separated by white space on the + line. The arguments may contain quoted strings and variable substitutions, + described below, and in some cases contain multiple words. The + object and verb are single words from a pre- + defined set. +
+ + The object in a pattern is the name of an element of the message, + such as src or data, or the special case arg, which refers to + the argument component of the current rule. The object in an action + is always the word plumb. +
+ + The verbs in the pattern rules describe how the objects and arguments + are to be interpreted. Within a rule set, the patterns are evaluated + in sequence; if one fails, the rule set fails. Some verbs are + predicates that check properties of the message; others rewrite + components of the message and implicitly always succeed. + Such rewritings are permanent, so rules that specify them should + be placed after all pattern-matching rules in the rule set.
+ +
+ + add      The object must be attr. Append the argument, which must be + a sequence of name=value pairs, to the list of attributes of the + message.
+ delete   The object must be attr. If the message has an attribute + whose name is the argument, delete it from the list of attributes + of the message. (Even if the message does not, the rule matches + the message.)
+ is       If the text of the object is identical to the text of the argument, + the rule matches.
+ isdir    If the text of the object is the name of an existing directory, + the rule matches and sets the variable $dir to that directory + name.
+ isfile   If the text of the object is the name of an existing file + (not a directory), the rule matches and sets the variable $file + to that file name.
+ matchesIf the entire text of the object matches the regular expression + specified in the argument, the rule matches. This verb is described + in more detail below.
+ set      The value of the object is set to the value of the argument.
+ +
+ + +
+ The matches verb has special properties that enable the rules + to select which portion of the data is to be sent to the destination. + By default, a data matches rule requires that the entire text + matches the regular expression. If, however, the message has an + attribute named click, that reports that the message was + produced by a mouse click within the text and that the regular + expressions in the rule set should be used to identify what portion + of the data the user intended. Typically, a program such as an + editor will send a white-space delimited block of text containing + the mouse click, using the value of the click attribute (a + number starting from 0) to indicate where in the textual data + the user pointed. +
+ + When the message has a click attribute, the data matches rules + extract the longest leftmost match to the regular expression that + contains or abuts the textual location identified by the click. + For a sequence of such rules within a given rule set, each regular + expression, evaluated by this specification, must + match the same subset of the data for the rule set to match the + message. For example, here is a pair of patterns that identify + a message whose data contains the name of an existing file with + a conventional ending for an encoded picture file:
+ +
+ + data matches '[a−zA−Z0−9_–./]+' + data matches '([a−zA−Z0−9_–./]+).(jpe?g|gif|bit|ps|pdf)' + +
+ The first expression extracts the largest subset of the data around + the click that contains file name characters; the second sees + if it ends with, for example, .jpeg. If only the second pattern + were present, a piece of text horse.gift could be misinterpreted + as an image file named horse.gif. +
+ + If a click attribute is specified in a message, it will be deleted + by the plumber before sending the message if the data matches + rules expand the selection. +
+ + The action rules all have the object plumb. There are only three + verbs for action rules:
+ +
+ + to       The argument is the name of the port to which the message will + be sent. If the message has a destination specified, it must match + the to port of the rule set or the entire rule set will be skipped. + (This is the only rule that is evaluated out of order.)
+ client   If no application has the port open, the arguments to a + plumb start rule specify a shell program to run in response to + the message. The message will be held, with the supposition that + the program will eventually open the port to retrieve it.
+ start    Like client, but the message is discarded. Only one start + or client rule should be specified in a rule set.
+ +
+ + +
+ The arguments to all rules may contain quoted strings, exactly + as in rc(1). They may also contain simple string variables, identified + by a leading dollar sign $. Variables may be set, between rule + sets, by assignment statements in the style of rc. Only one variable + assignment may appear on a line. The plumber also + maintains some built-in variables:
+ +
+ + $0      The text that matched the entire regular expression in a previous + data matches rule. $1, $2, etc. refer to text matching the first, + second, etc. parenthesized subexpression.
+ $attr   The textual representation of the attributes of the message.
+ $data   The contents of the data field of the message.
+ $dir    The directory name resulting from a successful isdir rule. + If no such rule has been applied, it is the string constructed + syntactically by interpreting data as a file name in wdir.
+ $dst    The contents of the dst field of the message.
+ $file   The file name resulting from a successful isfile rule. If + no such rule has been applied, it is the string constructed syntactically + by interpreting data as a file name in wdir.
+ $type   The contents of the type field of the message.
+ $src    The contents of the src field of the message.
+ $wdir   The contents of the wdir field of the message.
+ $plan9The root directory of the Plan 9 tree (see get9root(3)).
+ +
+ +
+

EXAMPLE
+ +
+ + The following is a modest, representative file of plumbing rules.
+ # these are generally in order from most specific to least, + # since first rule that fires wins. + addr=':(#?[0−9]+)' + protocol='(https?|ftp|file|gopher|mailto|news|nntp|telnet|wais)' + domain='[a−zA−Z0−9_@]+([.:][a−zA−Z0−9_@]+)*/?[a−zA−Z0−9_?,%#~&/\−]+' + file='([:.][a−zA−Z0−9_?,%#~&/\−]+)*' + # image files go to page + type is text + data matches '[a−zA−Z0−9_\−./]+' + data matches '([a−zA−Z0−9_\−./]+).(jpe?g|gif|bit)' + arg isfile $0 + plumb to image + plumb start page −w $file + # URLs go to web browser + type is text + data matches $protocol://$domain$file + plumb to web + plumb start window webbrowser $0 + # existing files, possibly tagged by line number, go to edit/sam + type is text + data matches '([.a−zA−Z0−9_/–]+[a−zA−Z0−9_/\−])('$addr')?' + arg isfile $1 + data set $file + attr add addr=$3 + plumb to edit + plumb start window sam $file + # .h files are looked up in /sys/include and passed to edit/sam + type is text + data matches '([a−zA−Z0−9]+\.h)('$addr')?' + arg isfile /sys/include/$1 + data set $file + attr add addr=$3 + plumb to edit + plumb start window sam $file + + + + The following simple plumbing rules file is a good beginning set + of rules.
+ # to update: cp /usr/$user/lib/plumbing /mnt/plumb/rules + editor = acme + # or editor = sam + include basic + +
+

FILES
+ +
+ + $HOME/lib/plumbing default rules file.
+ plumb service name for plumber(4).
+ /usr/local/plan9/plumb + +
+ + +
+ + directory for include files.
+ +
+ +
+ /usr/local/plan9/plumb/fileaddr + +
+ + +
+ + public macro definitions.
+ +
+ +
+ /usr/local/plan9/plumb/basic + +
+ + +
+ + basic rule set.
+ +
+ +
+ +
+

SEE ALSO
+ +
+ + plumb(1), plumb(3), plumber(4), regexp(7)
+ +
+ +

+ + +

		+
	+ + + +

+ + diff --git a/man/man7/regexp.html b/man/man7/regexp.html new file mode 100644 index 00000000..1bc2c74e --- /dev/null +++ b/man/man7/regexp.html @@ -0,0 +1,131 @@ + +regexp(7) - Plan 9 from User Space + + + + +

REGEXP(7) REGEXP(7) +

+
+

NAME
+ +
+ + regexp – Plan 9 regular expression notation
+ +
+

DESCRIPTION
+ +
+ + This manual page describes the regular expression syntax used + by the Plan 9 regular expression library regexp(3). It is the + form used by egrep(1) before egrep got complicated. +
+ + A regular expression specifies a set of strings of characters. + A member of this set of strings is said to be matched by the regular + expression. In many applications a delimiter character, commonly + /, bounds a regular expression. In the following specification + for regular expressions the word ‘character’ means any + character (rune) but newline. +
+ + The syntax for a regular expression e0 is
+ +
+ + e3: literal | charclass | '.' | '^' | '$' | '(' e0 ')' + e2: e3 + + + + | e2 REP + + + REP: '*' | '+' | '?' + e1: e2 + + + + | e1 e2 + + + e0: e1 + + + + | e0 '|' e1 + + + + + +
+ + + +
+ +
+ A literal is any non-metacharacter, or a metacharacter (one of + .*+?[]()|\^$), or the delimiter preceded by \. +
+ + A charclass is a nonempty string s bracketed [s] (or [^s]); it + matches any character in (or not in) s. A negated character class + never matches newline. A substring a−b, with a and b in ascending + order, stands for the inclusive range of characters between a + and b. In s, the metacharacters −, ], an initial ^, and the + regular expression delimiter must be preceded by a \; other metacharacters + have no special meaning and may appear unescaped. +
+ + A . matches any character. +
+ + A ^ matches the beginning of a line; $ matches the end of the + line. +
+ + The REP operators match zero or more (*), one or more (+), zero + or one (?), instances respectively of the preceding regular expression + e2. +
+ + A concatenated regular expression, e1e2, matches a match to e1 + followed by a match to e2. +
+ + An alternative regular expression, e0|e1, matches either a match + to e0 or a match to e1. +
+ + A match to any part of a regular expression extends as far as + possible without preventing a match to the remainder of the regular + expression.
+ +
+

SEE ALSO
+ +
+ + regexp(3)
+ +
+ +

+ + +

		+
	+ + + +

+ + diff --git a/man/man7/thumbprint.html b/man/man7/thumbprint.html new file mode 100644 index 00000000..eccbe595 --- /dev/null +++ b/man/man7/thumbprint.html @@ -0,0 +1,68 @@ + +thumbprint(7) - Plan 9 from User Space + + + + +

THUMBPRINT(7) THUMBPRINT(7) +

+
+

NAME
+ +
+ + thumbprint – public key thumbprints
+ +
+

DESCRIPTION
+ +
+ + +
+ + Applications in Plan 9 that use public keys for authentication, + for example by calling tlsClient and okThumbprint (see pushtls(3)), + check the remote side’s public key by comparing against thumbprints + from a trusted list. The list is maintained by people who set + local policies about which servers can be trusted + for which applications, thereby playing the role taken by certificate + authorities in PKI-based systems. By convention, these lists are + stored as files in /sys/lib/tls/ and protected by normal file + system permissions. +
+ + Such a thumbprint file comprises lines made up of attribute/value + pairs of the form attr=value or attr. The first attribute must + be x509 and the second must be sha1={hexchecksumofbinarycertificate}. + All other attributes are treated as comments. The file may also + contain lines of the form #includefile +
+ + For example, a web server might have thumbprint
+ x509 sha1=8fe472d31b360a8303cd29f92bd734813cbd923c cn=*.cs.bell−labs.com + +
+

SEE ALSO
+ +
+ + pushtls(3)
+ +
+ +

+ + +

		+
	+ + + +

+ + diff --git a/man/man7/utf.html b/man/man7/utf.html new file mode 100644 index 00000000..a1e767ec --- /dev/null +++ b/man/man7/utf.html @@ -0,0 +1,96 @@ + +utf(7) - Plan 9 from User Space + + + + +

UTF(7)

UTF(7) +

+
+

NAME
+ +
+ + UTF, Unicode, ASCII, rune – character set and format
+ +
+

DESCRIPTION
+ +
+ + The Plan 9 character set and representation are based on the Unicode + Standard and on the ISO multibyte UTF-8 encoding (Universal Character + Set Transformation Format, 8 bits wide). The Unicode Standard + represents its characters in 16 bits; UTF-8 represents such values + in an 8-bit byte stream. Throughout this + manual, UTF-8 is shortened to UTF. +
+ + In Plan 9, a rune is a 16-bit quantity representing a Unicode + character. Internally, programs may store characters as runes. + However, any external manifestation of textual information, in + files or at the interface between programs, uses a machine-independent, + byte-stream encoding called UTF. +
+ + UTF is designed so the 7-bit ASCII set (values hexadecimal 00 + to 7F), appear only as themselves in the encoding. Runes with + values above 7F appear as sequences of two or more bytes with + values only from 80 to FF. +
+ + The UTF encoding of the Unicode Standard is backward compatible + with ASCII: programs presented only with ASCII work on Plan 9 + even if not written to deal with UTF, as do programs that deal + with uninterpreted byte streams. However, programs that perform + semantic processing on ASCII graphic characters must convert + from UTF to runes in order to work properly with non-ASCII input. + See rune(3). +
+ + Letting numbers be binary, a rune x is converted to a multibyte + UTF sequence as follows: +
+ + 01. x in [00000000.0bbbbbbb] → 0bbbbbbb
+ 10. x in [00000bbb.bbbbbbbb] → 110bbbbb, 10bbbbbb
+ 11. x in [bbbbbbbb.bbbbbbbb] → 1110bbbb, 10bbbbbb, 10bbbbbb
+ +
+ + Conversion 01 provides a one-byte sequence that spans the ASCII + character set in a compatible way. Conversions 10 and 11 represent + higher-valued characters as sequences of two or three bytes with + the high bit set. Plan 9 does not support the 4, 5, and 6 byte + sequences proposed by X-Open. When there are + multiple ways to encode a value, for example rune 0, the shortest + encoding is used. +
+ + In the inverse mapping, any sequence except those described above + is incorrect and is converted to rune hexadecimal 0080.
+ +
+

SEE ALSO
+ +
+ + ascii(1), tcs(1), rune(3), The Unicode Standard.
+ +
+ +

+ + +

		+
	+ + + +

+ + -- cgit v1.2.3