9pserve(4) - Plan 9 from User Space

From adc93f6097615f16d57e8a24a256302f2144ec4e Mon Sep 17 00:00:00 2001 From: rsc Date: Fri, 14 Jan 2005 17:37:50 +0000 Subject: cut out the html - they're going to cause diffing problems. --- man/man4/9pserve.html | 79 --------------- man/man4/acme.html | 268 -------------------------------------------------- man/man4/import.html | 107 -------------------- man/man4/index.html | 49 --------- man/man4/intro.html | 92 ----------------- man/man4/plumber.html | 122 ----------------------- man/man4/ramfs.html | 81 --------------- 7 files changed, 798 deletions(-) delete mode 100644 man/man4/9pserve.html delete mode 100644 man/man4/acme.html delete mode 100644 man/man4/import.html delete mode 100644 man/man4/index.html delete mode 100644 man/man4/intro.html delete mode 100644 man/man4/plumber.html delete mode 100644 man/man4/ramfs.html (limited to 'man/man4') diff --git a/man/man4/9pserve.html b/man/man4/9pserve.html deleted file mode 100644 index c9f2c3b7..00000000 --- a/man/man4/9pserve.html +++ /dev/null @@ -1,79 +0,0 @@ - -9pserve(4) - Plan 9 from User Space - - - - -

9PSERVE(4) 9PSERVE(4) -

-
-

NAME
- -
- - 9pserve – announce and multiplex 9P service
- -
-

SYNOPSIS
- -
- - 9pserve [ −v ] addr
- -
-

DESCRIPTION
- -
- - On Plan 9, when a user-level file server mounts itself into a - name space or posts itself in /srv, the Plan 9 kernel multiplexes - the potentially many processes accessing the server into a single - 9P conversation. The user-level server need not concern itself - with how many processes are accessing it or with cleaning up - after a process when it exits unexpectedly. On Unix, 9pserve takes - the place of the Plan 9 kernel, multiplexing clients onto a single - server conversation and cleaning up after clients when they hang - up unexpectedly. -
- - 9pserve announces a 9P service on addr and multiplexes any 9P - clients connecting to addr into a single conversation with a 9P - server on 9pserve’s standard input and output. When a client hangs - up, 9pserve flushes any outstanding 9P transactions and clunks - any outstanding fids belonging to the client. -
- - 9pserve is typically not invoked directly; use post9pservice(3) - instead.
- -
-

SEE ALSO
- -
- - intro(4), intro(9p)
- -
-

SOURCE
- -
- - /usr/local/plan9/src/cmd/9pserve.c - -
- -

- - -

		-
	- - - -

- - diff --git a/man/man4/acme.html b/man/man4/acme.html deleted file mode 100644 index ac310c13..00000000 --- a/man/man4/acme.html +++ /dev/null @@ -1,268 +0,0 @@ - -acme(4) - Plan 9 from User Space - - - - -

ACME(4) ACME(4) -

-
-

NAME
- -
- - acme – control files for text windows
- -
-

SYNOPSIS
- -
- - acme [ −f varfont ] [ −F fixfont ] [ file ... ]
- -
-

DESCRIPTION
- -
- - The text window system acme(1) serves a variety of files for reading, - writing, and controlling windows. Some of them are virtual versions - of system files for dealing with the virtual console; others control - operations of acme itself. When a command is run under acme, a - directory holding these files is posted as the 9P - service acme (using 9pserve(4)). -
- - Some of these files supply virtual versions of services available - from the underlying environment, in particular the character terminal - files in Plan 9’s cons(3). (Unlike in Plan 9’s rio(1), each command - under acme sees the same set of files; there is not a distinct - /dev/cons for each window.) Other files are unique to - acme.
- acmeis a subdirectory used by win (see acme(1)) as a mount point - for the acme files associated with the window in which win is - running. It has no specific function under acme itself.
- consis the standard and diagnostic output file for all commands - run under acme. (Input for commands is redirected to /dev/null.) - Text written to cons appears in a window labeled dir/+Errors, - where dir is the directory in which the command was run. The window - is created if necessary, but not until text is - -
- - actually written.
- -
- consctl - -
- - Is an empty unwritable file present only for compatibility; there - is no way to turn off ‘echo’, for example, under acme.
- -
- index - -
- - holds a sequence of lines of text, one per window. Each line has - 5 decimal numbers, each formatted in 11 characters plus a blank--the - window ID; number of characters (runes) in the tag; number of - characters in the body; a 1 if the window is a directory, 0 otherwise; - and a 1 if the window is modified, 0 - otherwise--followed by the tag up to a newline if present. Thus - at character position 5x12 starts the name of the window. If a - file has multiple zeroxed windows open, only the most recently - used will appear in the index file.
- -
- label - -
- - is an empty file, writable without effect, present only for compatibility - with rio.
- -
- new   A directory analogous to the numbered directories (q.v.). Accessing - any file in new creates a new window. Thus to cause text to appear - in a new window, write it to /dev/new/body. For more control, - open /dev/new/ctl and use the interface described below. -
- - -
- - Each acme window has associated a directory numbered by its ID. - Window IDs are chosen sequentially and may be discovered by the - ID command, by reading the ctl file, or indirectly through the - index file. The files in the numbered directories are as follows.
- addrmay be written with any textual address (line number, regular - expression, etc.), in the format understood by button 3 but without - the initial colon, including compound addresses, to set the address - for text accessed through the data file. When read, it returns - the value of the address that would next be read or - -
- - written through the data file, in the format #m,#n where m and - n are character (not byte) offsets. If m and n are identical, - the format is just #m. Thus a regular expression may be evaluated - by writing it to addr and reading it back. The addr address has - no effect on the user’s selection of text. - -
- bodyholds contents of the window body. It may be read at any byte - offset. Text written to body is always appended; the file offset - is ignored.
- ctl   may be read to recover the five numbers as held in the index - file, described above, plus two more fields: the width of the - window in pixels and the name of the font used in the window. - Text messages may be written to ctl to affect the window. Each - message is terminated by a newline and multiple messages - -
- - may be sent in a single write.
- -
- - addr=dot     Set the addr address to that of the user’s selected text - in the window.
- clean        Mark the window clean as though it has just been written.
- dirty        Mark the window dirty, the opposite of clean.
- cleartag     Remove all text in the tag after the vertical bar.
- del          Equivalent to the Del interactive command.
- delete       Equivalent to the Delete interactive command.
- dot=addr     Set the user’s selected text in the window to the text - addressed by the addr address.
- dump commandSet the command string to recreate the window from - a dump file.
- dumpdir directory
- Set the directory in which to run the command to recreate the - window from a dump file.
- get          Equivalent to the Get interactive command with no arguments; - accepts no arguments.
- limit=addr   When the ctl file is first opened, regular expression - context searches in addr addresses examine the whole file; this - message restricts subsequent searches to the current addr address.
- mark         Cancel nomark, returning the window to the usual state wherein - each modification to the body must be undone individually.
- name name     Set the name of the window to name.
- nomark       Turn off automatic ‘marking’ of changes, so a set of related - changes may be undone in a single Undo interactive command.
- noscroll     Turn off automatic ‘scrolling’ of the window to show text - written to the body.
- put          Equivalent to the Put interactive command with no arguments; - accepts no arguments.
- scroll       Cancel a noscroll message, returning the window to the default - state wherein each write to the body file causes the window to - ‘scroll’ to display the new text.
- show         Guarantee at least some of the selected text is visible on - the display.
- -
- -
- datais used in conjunction with addr for random access to the - contents of the body. The file offset is ignored when writing - the data file; instead the location of the data to be read or - written is determined by the state of the addr file. Text, which - must contain only whole characters (no ‘partial runes’), written - to - -
- - data replaces the characters addressed by the addr file and sets - the address to the null string at the end of the written text. - A read from data returns as many whole characters as the read - count will permit starting at the beginning of the addr address - (the end of the address has no effect) and sets the - address to the null string at the end of the returned characters.
- -
- event - -
- - When a window’s event file is open, changes to the window occur - as always but the actions are also reported as messages to the - reader of the file. Also, user actions with buttons 2 and 3 (other - than chorded Cut and Paste, which behave normally) have no immediate - effect on the window; it is expected that - the program reading the event file will interpret them. The messages - have a fixed format: a character indicating the origin or cause - of the action, a character indicating the type of the action, - four free-format blank-terminated decimal numbers, optional text, - and a newline. The first and second numbers are - the character addresses of the action, the third is a flag, and - the final is a count of the characters in the optional text, which - may itself contain newlines. The origin characters are E for writes - to the body or tag file, F for actions through the window’s other - files, K for the keyboard, and M for the mouse. The - type characters are D for text deleted from the body, d for text - deleted from the tag, I for text inserted to the body, i for text - inserted to the tag, L for a button 3 action in the body, l for - a button 3 action in the tag, X for a button 2 action in the body, - and x for a button 2 action in the tag. - If the relevant text has less than 256 characters, it is included - in the message; otherwise it is elided, the fourth number is 0, - and the program must read it from the data file if needed. No - text is sent on a D or d message.
- For D, d, I, and i the flag is always zero. For X and x, the flag - is a bitwise OR (reported decimally) of the following: 1 if the - text indicated is recognized as an acme built-in command; 2 if - the text indicated is a null string that has a non-null expansion; - if so, another complete message will follow describing the - expansion exactly as if it had been indicated explicitly (its - flag will always be 0); 8 if the command has an extra (chorded) - argument; if so, two more complete messages will follow reporting - the argument (with all numbers 0 except the character count) and - where it originated, in the form of a fully-qualified - button 3 style address.
- For L and l, the flag is the bitwise OR of the following: 1 if - acme can interpret the action without loading a new file; 2 if - a second (post-expansion) message follows, analogous to that with - X messages; 4 if the text is a file or window name (perhaps with - address) rather than plain literal text. - For messages with the 1 bit on in the flag, writing the message - back to the event file, but with the flag, count, and text omitted, - will cause the action to be applied to the file exactly as it - would have been if the event file had not been open.
- -
- tag   holds contents of the window tag. It may be read at any byte - offset. Text written to tag is always appended; the file offset - is ignored.
- -
-

SOURCE
- -
- - /usr/local/plan9/src/cmd/acme - -
-

SEE ALSO
- -
- - rio(1), acme(1)
- -
- -

- - -

		-
	- - - -

- - diff --git a/man/man4/import.html b/man/man4/import.html deleted file mode 100644 index e0eca5cb..00000000 --- a/man/man4/import.html +++ /dev/null @@ -1,107 +0,0 @@ - -import(4) - Plan 9 from User Space - - - - -

IMPORT(4) IMPORT(4) -

-
-

NAME
- -
- - import – import 9P resources from another system
- -
-

SYNOPSIS
- -
- - import [ −df ] [ −n ns ] [ −p prog ] [ −s service ] system
- -
-

DESCRIPTION
- -
- - Import presents the 9P service service (default plumb) running - on system as a service on the local system, in the current name - space. -
- - The −n option sets the remote name space directory where import - should expect to find service. If it is not specified, import - uses name of the local system’s name space directory. (Since name - space directories are conventionally inside /tmp, the path have - different meanings on the two systems.) -
- - Import connects to system using ssh(1). It invokes import on the - remote system to carry out the remote side of the protocol. The - −p option specifies the path to import on the remote system, in - case it is not in the system search path. -
- - The −d option turns on debugging. The −f option keeps import from - forking itself into the background, also useful for debugging.
- -
-

EXAMPLE
- -
- - Suppose you run sam −r to the CPU server anna. Sam wants to talk - to a plumber on the local terminal, but the file names will refer - to files on anna. -
- - To fix this problem, create a new name space directory and start - a new plumber on anna:
- -
- - remotens=/tmp/ns.`whoami`.on.`hostname` - ssh anna mkdir $remotens - ssh anna NAMESPACE=$remotens plumber -Now import that plumber to the local name space before starting - sam and 9term:
- NAMESPACE=/tmp/ns.anna - mkdir $NAMESPACE - import −n $remotens −s plumb anna - sam & - 9term ssh anna & - -
- -
-

SOURCE
- -
- - /usr/local/plan9/src/cmd/import.c - -
-

SEE ALSO
- -
- - 9pserve(4), intro(4)
- -
- -

- - -

		-
	- - - -

- - diff --git a/man/man4/index.html b/man/man4/index.html deleted file mode 100644 index bef356e8..00000000 --- a/man/man4/index.html +++ /dev/null @@ -1,49 +0,0 @@ - - -Manual Section 4 - Plan 9 from User Space - - - -

- - -

	-
- - Manual Section 4 - Plan 9 from User Space - -
-
intro(4)	intro – introduction to file servers -
-
-
-
9pserve(4)	9pserve – announce and multiplex 9P service -
-
-
-
acme(4)	acme – control files for text windows -
-
-
-
import(4)	import – import 9P resources from another system -
-
-
-
plumber(4)	plumber – file system for interprocess messaging -
-
-
-
ramfs(4)	ramfs – memory file system -

- - -

		-
	- - - -

- - diff --git a/man/man4/intro.html b/man/man4/intro.html deleted file mode 100644 index ec2409c0..00000000 --- a/man/man4/intro.html +++ /dev/null @@ -1,92 +0,0 @@ - -intro(4) - Plan 9 from User Space - - - - -

INTRO(4) INTRO(4) -

-
-

NAME
- -
- - intro – introduction to file servers
- -
-

DESCRIPTION
- -
- - A Plan 9 file server provides a file tree to processes. This section - of the manual describes servers that can be mounted in a name - space to give a file-like interface to interesting services. A - file server may be a provider of a conventional file system, with - files maintained on permanent storage, or it may also be a process - that synthesizes files in some manner. -
- - In Plan 9, the kernel mount device mnt(3) acts as a client to - the 9P servers mounted in the current name space, translating - system calls such as open(2) into 9P transactions such as open(9p). - The kernel also multiplexes the potentially many processes onto - a single 9P conversation with each server. Finally, the kernel - provides each process with its own private name space which it - can customize at will. Modern Unix systems do not provide these - niceties, so the Unix port of these Plan 9 file servers provides - them via other means. -
- - On Unix, 9P clients do not access servers via the traditional - file system call interface. Only the Unix name space can be accessed - that way. Instead, 9P clients use the 9pclient(3) library to connect - and interact directly with particular 9P servers. The 9p(1) command-line - client is useful for interactive use and in shell - scripts. -
- - To preserve the façade of a single 9P conversation with each server, - 9P servers invoke 9pserve(4), typically via post9pservice(3). - 9pserve announces a 9P service at a particular network address - and multiplexes the clients that connect to that address onto - a single 9P conversation with the server. -
- - Each ported program operates in a pseudo-name space that determines - which 9P servers it is using. The name space of a ported program - is represented by a directory containing Unix domain sockets, - one for each 9P server. The directory defaults to /tmp/ns.$USER.$DISPLAY, - meaning that all programs in an X - Windows login session share a single name space. Setting the $NAMESPACE - environment variable overrides this default. The namespace(1) - command prints the current name space directory. -
- - Occasionally it is useful to be able to connect the input or output - of a standard Unix program to a file served by a 9P server. The - new openfd(9p) 9P transaction, which depends on file descriptor - passing, provides a sufficient workaround in many cases. 9pserve’s - implementation of openfd (see also fsopenfd in - 9pclient(3)) returns the read or write end of a pipe; a helper - process transfers data between the other end of the pipe and the - 9P server. Note that since the data is being transferred via a - pipe, 9P read and write errors cannot be passed on to the Unix - program. The Unix program sees only end-of-file or a closed pipe. - -
- -

- - -

		-
	- - - -

- - diff --git a/man/man4/plumber.html b/man/man4/plumber.html deleted file mode 100644 index 83e5943f..00000000 --- a/man/man4/plumber.html +++ /dev/null @@ -1,122 +0,0 @@ - -plumber(4) - Plan 9 from User Space - - - - -

PLUMBER(4) PLUMBER(4) -

-
-

NAME
- -
- - plumber – file system for interprocess messaging
- -
-

SYNOPSIS
- -
- - plumber [ −p plumbing ]
- -
-

DESCRIPTION
- -
- - The plumber is a user-level file server that receives, examines, - rewrites, and dispatches plumb(7) messages between programs. Its - behavior is programmed by a plumbing file (default $HOME/lib/plumbing) - in the format of plumb(7). -
- - Its services are posted via 9pserve(4) as plumb. and consist of - two pre-defined files, plumb/send and plumb/rules, and a set of - output ports for dispatching messages to applications. -
- - Programs use fswrite (see 9pclient(3)) to deliver messages to - the send file, and fsread to receive them from the corresponding - port. For example, sam(1)’s plumb menu item or the B command cause - a message to be sent to plumb/send; sam in turn reads from, by - convention, plumb/edit to receive - messages about files to open. -
- - A copy of each message is sent to each client that has the corresponding - port open. If none has it open, and the rule has a plumb client - or plumb start rule, that rule is applied. A plumb client rule - causes the specified command to be run and the message to be held - for delivery when the port is opened. A - plumb start rule runs the command but discards the message. If - neither start or client is specified and the port is not open, - the message is discarded and a write error is returned to the - sender. -
- - The set of output ports is determined dynamically by the specification - in the plumbing rules file: a port is created for each unique - destination of a plumb to rule. -
- - The set of rules currently active may be examined by reading the - file plumb/rules; appending to this file adds new rules to the - set, while creating it (opening it with OTRUNC) clears the rule - set. Thus the rule set may be edited dynamically with a traditional - text editor. However, ports are never deleted dynamically; - if a new set of rules does not include a port that was defined - in earlier rules, that port will still exist (although no new - messages will be delivered there).
- -
-

FILES
- -
- - $HOME/lib/plumbing default rules file
- /usr/local/plan9/plumb - -
- - -
- - directory to search for files in include statements
- -
- -
- plumb mount name for plumber(4).
- -
-

SOURCE
- -
- - /usr/local/plan9/src/cmd/plumb - -
-

SEE ALSO
- -
- - plumb(1), plumb(3), plumb(7)
- -
- -

- - -

		-
	- - - -

- - diff --git a/man/man4/ramfs.html b/man/man4/ramfs.html deleted file mode 100644 index 7fb86f5a..00000000 --- a/man/man4/ramfs.html +++ /dev/null @@ -1,81 +0,0 @@ - -ramfs(4) - Plan 9 from User Space - - - - -

RAMFS(4) RAMFS(4) -

-
-

NAME
- -
- - ramfs – memory file system
- -
-

SYNOPSIS
- -
- - ramfs [ −i ] [ −S service ]
- -
-

DESCRIPTION
- -
- - Ramfs starts a 9P file server keeping all files in memory. Initially - the file tree is empty. -
- - By default ramfs posts its service as ramfs using 9pserve(4). - -
- - The −S flag specifies an alternate service name for ramfs to use. - -
- - The −i flag tells ramfs to use file descriptors 0 and 1 for its - communication channel rather than create a pipe. This makes it - possible to use ramfs as a file server on a remote machine: the - file descriptors 0 and 1 will be the network channel from ramfs - to the client machine. -
- - This program is useful mainly as an example of how to write a - user-level file server. It can also be used to provide high-performance - temporary files.
- -
-

SOURCE
- -
- - /usr/local/plan9/src/cmd/ramfs.c - -
-

SEE ALSO
- -
- - 9p(3), 9pserve(4)
- -
- -

- - -

		-
	- - - -

- - -- cgit v1.2.3