on master help sign in
clay tasks - fix style
19e30a4tinnus-napbus
content/docs/arvo/clay/examples.md+21−22
@@ -8,31 +8,31 @@ template = "doc.html"
8
8
9- [Introduction](#introduction)
9- [Introduction](#introduction)
10- [%warp](#warp) - Read and Subscribe.
10- [%warp](#warp) - Read and Subscribe.
11− - [%sing](#sing) - Read a file or directory.
11+ - [%sing](#sing) - Read a file or directory.
12− - [%next](#next) - Subscribe for the next change to a file or directory.
12+ - [%next](#next) - Subscribe for the next change to a file or directory.
13− - [%mult](#mult) - Subscribe for the next change to a set of files and/or directories.
13+ - [%mult](#mult) - Subscribe for the next change to a set of files and/or directories.
14− - [%many](#many) - Track changes to a `desk` for the specified range of revisions.
14+ - [%many](#many) - Track changes to a `desk` for the specified range of revisions.
15− - [Cancel Subscription](#cancel-subscription)
15+ - [Cancel Subscription](#cancel-subscription)
16- [%info](#info) - Write and Modify.
16- [%info](#info) - Write and Modify.
17− - [%ins](#ins) - Add a file.
17+ - [%ins](#ins) - Add a file.
18− - [%del](#del) - Delete a file.
18+ - [%del](#del) - Delete a file.
19− - [%mut](#mut) - Change a file.
19+ - [%mut](#mut) - Change a file.
20− - [Multiple Changes](#multiple-changes) - Change multiple files.
20+ - [Multiple Changes](#multiple-changes) - Change multiple files.
21- [Manage Mounts](#manage-mounts)
21- [Manage Mounts](#manage-mounts)
22− - [%boat](#boat) - List mounts.
22+ - [%boat](#boat) - List mounts.
23− - [%mont](#mont) - Mount something.
23+ - [%mont](#mont) - Mount something.
24− - [%ogre](#ogre) - Unmount something.
24+ - [%ogre](#ogre) - Unmount something.
25− - [%dirk](#dirk) - Commit changes.
25+ - [%dirk](#dirk) - Commit changes.
26- [Merge Desks](#merge-desks)
26- [Merge Desks](#merge-desks)
27− - [%merg](#merg)
27+ - [%merg](#merg)
28- [Permissions](#permissions)
28- [Permissions](#permissions)
29− - [%perm](#perm) - Set file permissions.
29+ - [%perm](#perm) - Set file permissions.
30− - [%cred](#cred) - Add permission group.
30+ - [%cred](#cred) - Add permission group.
31− - [%crew](#crew) - Get permission groups.
31+ - [%crew](#crew) - Get permission groups.
32− - [%crow](#crow) - Get group usage.
32+ - [%crow](#crow) - Get group usage.
33- [Foreign Ships](#foreign-ships)
33- [Foreign Ships](#foreign-ships)
34− - [%warp](#warp-remote) - Read a file on a foreign ship.
34+ - [%warp](#warp-remote) - Read a file on a foreign ship.
35− - [%merg](#merg-remote) - Merge from a foreign `desk`.
35+ - [%merg](#merg-remote) - Merge from a foreign `desk`.
36
36
37# Introduction
37# Introduction
38
38
@@ -63,13 +63,12 @@ Most examples will either use `|pass` to just send a `task` or the following thr
63
63
64# `%warp`
64# `%warp`
65
65
66−See the [Read and Subscribe](/docs/arvo/clay/tasks#warp) section of the [API Reference](/docs/arvo/clay/tasks) document for general details.
66+See the [Read and Subscribe](/docs/arvo/clay/tasks#warp---read-and-track) section of the [API Reference](/docs/arvo/clay/tasks) document for general details.
67
67
68## `%sing`
68## `%sing`
69
69
70Here we'll look at reading files by passing Clay a `%warp` `task` with a `%sing` `rave` and receiving a `%writ` `gift` containing the data in response.
70Here we'll look at reading files by passing Clay a `%warp` `task` with a `%sing` `rave` and receiving a `%writ` `gift` containing the data in response.
71
71
72−
73Using the `send-task-take-gift.hoon` thread, let's try reading `gen/hood/hi.hoon`:
72Using the `send-task-take-gift.hoon` thread, let's try reading `gen/hood/hi.hoon`:
74
73
75```
74```
content/docs/arvo/clay/tasks.md+101−153
@@ -4,49 +4,18 @@ weight = 6
4template = "doc.html"
4template = "doc.html"
5+++
5+++
6
6
7−# Contents
8−
9−- [Introduction](#introduction)
10−- [%warp](#warp) - Read and Subscribe.
11− - [%sing](#sing) - Read a file or directory.
12− - [%next](#next) - Subscribe for the next change to a file or directory.
13− - [%mult](#mult) - Subscribe for the next change to a set of files and/or directories.
14− - [%many](#many) - Track changes to a `desk` for the specified range of revisions.
15− - [Cancel Subscription](#cancel-subscription)
16−- [Write and Modify](#write-and-modify)
17− - [%info](#info)
18−- [Manage Mounts](#manage-mounts)
19− - [%boat](#boat) - List mounts.
20− - [%mont](#mont) - Mount something.
21− - [%ogre](#ogre) - Unmount something.
22− - [%dirk](#dirk) - Commit changes.
23−- [Merge Desks](#merge-desks)
24− - [%merg](#merg)
25−- [Permissions](#permissions)
26− - [%perm](#perm) - Set file permissions.
27− - [%cred](#cred) - Add permission group.
28− - [%crew](#crew) - Get permission groups.
29− - [%crow](#crow) - Get group usage.
30−- [Foreign Ships](#foreign-ships)
31− - [%warp](#warp-remote) - Read a file on a foreign ship.
32− - [%merg](#merg-remote) - Merge from a foreign `desk`.
33−
34−# Introduction
35−
36−This document details all the `task`s you're likely to use to interact with Clay, as well as the `gift`s you'll receive in response. Each section has a corresponding practical example in the [Examples](/docs/arvo/clay/examples) document. Many of the types referenced are detailed in the [Data Types](/docs/arvo/clay/data-types) document. It may also be useful to look at the `++ clay` section of `/sys/lull.hoon` in Arvo where these `task`s, `gift`s and data structures are defined.
7+This document details all the `task`s you're likely to use to interact with Clay, as well as the `gift`s you'll receive in response. Each section has a corresponding practical example in the [Examples](/docs/arvo/clay/examples) document. Many of the types referenced are detailed in the [Data Types](/docs/arvo/clay/data-types) document. It may also be useful to look at the `++ clay` section of `/sys/lull.hoon` in Arvo where these `task`s, `gift`s and data structures are defined.
37
8
38The focus of this document is on interacting with Clay from userspace applications and threads, so it doesn't delve into the internal mechanics of Clay from a kernel development perspective.
9The focus of this document is on interacting with Clay from userspace applications and threads, so it doesn't delve into the internal mechanics of Clay from a kernel development perspective.
39
10
40−# `%warp`
11+## `%warp` - Read and track
41−
42−A `%warp` `task` is for reading a subscribing to files and directories.
43−
44−### Accepts
45
12
46```hoon
13```hoon
47−[wer=ship rif=riff]
14+[%warp wer=ship rif=riff]
48```
15```
49
16
17+A `%warp` `task` is for reading and subscribing to files and directories.
18+
50The `wer` field is the target ship. The `(unit rave)` of the [riff](/docs/arvo/clay/data-types#riff-clay-request-desist) is null to cancel an existing subscription, otherwise the [rave](/docs/arvo/clay/data-types#rave-clay-general-subscription-request) is tagged with one of:
19The `wer` field is the target ship. The `(unit rave)` of the [riff](/docs/arvo/clay/data-types#riff-clay-request-desist) is null to cancel an existing subscription, otherwise the [rave](/docs/arvo/clay/data-types#rave-clay-general-subscription-request) is tagged with one of:
51
20
52- `%sing` - Read a single file or directory.
21- `%sing` - Read a single file or directory.
@@ -56,7 +25,7 @@ The `wer` field is the target ship. The `(unit rave)` of the [riff](/docs/arvo/c
56
25
57We'll look at each of these in more detail below.
26We'll look at each of these in more detail below.
58
27
59−### Returns
28+#### Returns
60
29
61Clay responds to a `%mult` request with a `%wris` `gift`, and the rest with a `%writ` `gift`.
30Clay responds to a `%mult` request with a `%wris` `gift`, and the rest with a `%writ` `gift`.
62
31
@@ -76,7 +45,7 @@ The `unit` of the [riot](/docs/arvo/clay/data-types#riot-clay-response) will be
76
45
77Now we'll look at each of the `rave` request types in turn.
46Now we'll look at each of the `rave` request types in turn.
78
47
79−## `%sing`
48+### `%sing` - Read
80
49
81```hoon
50```hoon
82[%sing =mood]
51[%sing =mood]
@@ -88,11 +57,11 @@ The `care` of the [mood](/docs/arvo/clay/data-types#mood-clay-single-subscriptio
88
57
89The [case](/docs/arvo/clay/data-types#case-specifying-a-commit) specifies the `desk` revision and you can use whichever kind you prefer. The `path` will usually be a path to a file or directory like `/gen/hood/hi/hoon` but may be something else depending on the `care`.
58The [case](/docs/arvo/clay/data-types#case-specifying-a-commit) specifies the `desk` revision and you can use whichever kind you prefer. The `path` will usually be a path to a file or directory like `/gen/hood/hi/hoon` but may be something else depending on the `care`.
90
59
91−### Example
60+#### Example
92
61
93[See here for an example of using %sing.](/docs/arvo/clay/examples#sing)
62[See here for an example of using %sing.](/docs/arvo/clay/examples#sing)
94
63
95−## `%next`
64+### `%next` - Await next
96
65
97```hoon
66```hoon
98[%next =mood] :: await next version
67[%next =mood] :: await next version
@@ -102,19 +71,19 @@ This subscribes to the next version of the specified file. See [here](/docs/arvo
102
71
103If you subscribe to the current `case` of the `desk`, Clay will not respond until the file changes. If you subscribe to a previous `case` of the `desk` and the file has changed in between then and now, it will immediately return the first change it comes across in that range. For example, if you're currently at `case` `100`, subscribe to case `50` and the file in question has been modified at both `60` and `80`, clay will immediately return the version of the file at `case` `60`.
72If you subscribe to the current `case` of the `desk`, Clay will not respond until the file changes. If you subscribe to a previous `case` of the `desk` and the file has changed in between then and now, it will immediately return the first change it comes across in that range. For example, if you're currently at `case` `100`, subscribe to case `50` and the file in question has been modified at both `60` and `80`, clay will immediately return the version of the file at `case` `60`.
104
73
105−### Example
74+#### Example
106
75
107[See here for an example of using %next.](/docs/arvo/clay/examples#next)
76[See here for an example of using %next.](/docs/arvo/clay/examples#next)
108
77
109−## `%mult`
78+### `%mult` - Next of any
110
79
111```hoon
80```hoon
112−[%mult =mool] :: next version of any
81+[%mult =mool]
113```
82```
114
83
115−This subscribes to the next version of a `set` of files or directories. Clay will only send a single response, and it will send it when *any* of the specified files change. For example, if you subscribe to both `/foo/txt` and `/bar/txt`, and only `/foo/txt` changes, Clay will send a response indicating a change to `/foo/txt`. If `/bar/txt` changes subsequently, it will not tell you. If more than one file changes at once, it will tell you about each of the changes in the one response.
84+This subscribes to the next version of a `set` of files or directories. Clay will only send a single response, and it will send it when _any_ of the specified files change. For example, if you subscribe to both `/foo/txt` and `/bar/txt`, and only `/foo/txt` changes, Clay will send a response indicating a change to `/foo/txt`. If `/bar/txt` changes subsequently, it will not tell you. If more than one file changes at once, it will tell you about each of the changes in the one response.
116
85
117−The behaviour with respect to requesting old `case`s is the same as explained in the [`%next`](#next) section above.
86+The behaviour with respect to requesting old `case`s is the same as explained in the [`%next`](#next---await-next) section above.
118
87
119The `mool` specified in the request is this structure:
88The `mool` specified in the request is this structure:
120
89
@@ -122,16 +91,16 @@ The `mool` specified in the request is this structure:
122+$ mool [=case paths=(set (pair care path))] :: requests in desk
91+$ mool [=case paths=(set (pair care path))] :: requests in desk
123```
92```
124
93
125−You can use a different `care` for each of the files specified by the `path` if you like. Significantly, the `care` will determine whether Clay sends a response for a given change. For example, if you subscribe to an existing `/foo/txt` with a `%u` `care` and `/foo/txt` is modified but isn't deleted, Clay will *not* tell you. However, if you subscribe with an `%x` `care`, it *will* tell you.
94+You can use a different `care` for each of the files specified by the `path` if you like. Significantly, the `care` will determine whether Clay sends a response for a given change. For example, if you subscribe to an existing `/foo/txt` with a `%u` `care` and `/foo/txt` is modified but isn't deleted, Clay will _not_ tell you. However, if you subscribe with an `%x` `care`, it _will_ tell you.
126
95
127−### Example
96+#### Example
128
97
129[See here for an example of using %mult.](/docs/arvo/clay/examples#mult)
98[See here for an example of using %mult.](/docs/arvo/clay/examples#mult)
130
99
131−## `%many`
100+### `%many` - Track range
132
101
133```hoon
102```hoon
134−[%many track=? =moat] :: track range
103+[%many track=? =moat]
135```
104```
136
105
137This subscribes to all changes to a `desk` for the specified range of `case`s. Note that you're unlikely to use this directly, it's mostly used implicitly if you make a `%sing` or `%next` request with a `%v` `care` to a foreign `desk`. Regardless, we'll have a look at it for completeness.
106This subscribes to all changes to a `desk` for the specified range of `case`s. Note that you're unlikely to use this directly, it's mostly used implicitly if you make a `%sing` or `%next` request with a `%v` `care` to a foreign `desk`. Regardless, we'll have a look at it for completeness.
@@ -146,7 +115,7 @@ If the `track` is `%.y` it will just return a `%writ` like:
146
115
147If the `track` is `%.n`, the `cage` of the `%writ` will contain a [nako](/docs/arvo/clay/data-types#nako-subscription-response-data) with the relevant data for all changes to a desk between what you have and the `case` requested. It is very large and fairly complicated. The `nako` structure is defined in the `clay.hoon` source file itself rather than in `lull.hoon` or elsewhere since you're unlikely to work with it yourself.
116If the `track` is `%.n`, the `cage` of the `%writ` will contain a [nako](/docs/arvo/clay/data-types#nako-subscription-response-data) with the relevant data for all changes to a desk between what you have and the `case` requested. It is very large and fairly complicated. The `nako` structure is defined in the `clay.hoon` source file itself rather than in `lull.hoon` or elsewhere since you're unlikely to work with it yourself.
148
117
149−The `from` and `to` fields of the [moat](/docs/arvo/clay/data-types#moat-clay-range-subscription-request) specify the range of `case`s for which to subscribe. The range is *inclusive*. It can be specified by date or by revision number, whichever you prefer.
118+The `from` and `to` fields of the [moat](/docs/arvo/clay/data-types#moat-clay-range-subscription-request) specify the range of `case`s for which to subscribe. The range is _inclusive_. It can be specified by date or by revision number, whichever you prefer.
150
119
151The `path` in the `moat` is a path to a file or directory. If it's `~` it refers to the root of the `desk` in question. This lets you say "only inform me of changes to the `desk` if the specified file or directory exists". If it doesn't exist, Clay will not send you anything.
120The `path` in the `moat` is a path to a file or directory. If it's `~` it refers to the root of the `desk` in question. This lets you say "only inform me of changes to the `desk` if the specified file or directory exists". If it doesn't exist, Clay will not send you anything.
152
121
@@ -156,30 +125,28 @@ When you reach the end of the subscribed range of `case`s, Clay will send you a
156[%writ p=~]
125[%writ p=~]
157```
126```
158
127
159−### Example
128+#### Example
160
129
161[See here for an example of using %many.](/docs/arvo/clay/examples#many)
130[See here for an example of using %many.](/docs/arvo/clay/examples#many)
162
131
163−## Cancel Subscription
132+### Cancel Subscription
164
133
165To cancel a subscription, you just send a `%warp` with a null `(unit rave)` in the `riff`. Clay will cancel the subscription based on the `wire`. The request is exactly the same regardless of which type of `rave` you subscribed with originally.
134To cancel a subscription, you just send a `%warp` with a null `(unit rave)` in the `riff`. Clay will cancel the subscription based on the `wire`. The request is exactly the same regardless of which type of `rave` you subscribed with originally.
166
135
167−### Example
136+#### Example
168
137
169[See here for an example of cancelling a subscription.](/docs/arvo/clay/examples#cancel-subscription)
138[See here for an example of cancelling a subscription.](/docs/arvo/clay/examples#cancel-subscription)
170
139
171−# Write and Modify
140+## Write and Modify
172
141
173−## `%info`
142+### `%info` - Write
174−
175−To write or modify a file, we send Clay a `%info` `task`.
176−
177−### Accepts
178
143
179```hoon
144```hoon
180−[des=desk dit=nori]
145+[%info des=desk dit=nori]
181```
146```
182
147
148+To write or modify a file, we send Clay a `%info` `task`.
149+
183The `%|` tag in the [nori](/docs/arvo/clay/data-types#nori-clay-repository-action) is not currently supported and will crash with a `%labelling-not-implemented` if used, so you can focus on the `%&` part. The [soba](/docs/arvo/clay/data-types#soba-clay-delta) in the `nori` is just a list of changes so you can make more than one change in one request. Its `path` is just the path to a file like `/gen/hood/hi/hoon` and the [miso](/docs/arvo/clay/data-types#miso-clay-ankh-delta) is one of these types of requests:
150The `%|` tag in the [nori](/docs/arvo/clay/data-types#nori-clay-repository-action) is not currently supported and will crash with a `%labelling-not-implemented` if used, so you can focus on the `%&` part. The [soba](/docs/arvo/clay/data-types#soba-clay-delta) in the `nori` is just a list of changes so you can make more than one change in one request. Its `path` is just the path to a file like `/gen/hood/hi/hoon` and the [miso](/docs/arvo/clay/data-types#miso-clay-ankh-delta) is one of these types of requests:
184
151
185- `%del` - Delete a file.
152- `%del` - Delete a file.
@@ -187,11 +154,11 @@ The `%|` tag in the [nori](/docs/arvo/clay/data-types#nori-clay-repository-actio
187- `%dif` - This has not yet been implemented so will crash with a `%dif-not-implemented` error.
154- `%dif` - This has not yet been implemented so will crash with a `%dif-not-implemented` error.
188- `%mut` - Change a file. At the time of writing this behaves identically to `%ins` so its use merely informs the reader.
155- `%mut` - Change a file. At the time of writing this behaves identically to `%ins` so its use merely informs the reader.
189
156
190−### Returns
157+#### Returns
191
158
192Clay does not give any response to an `%info` `task` so don't expect a `sign` back.
159Clay does not give any response to an `%info` `task` so don't expect a `sign` back.
193
160
194−### Example
161+#### Example
195
162
196Here are examples of using each of these as well as making multiple changes in one request:
163Here are examples of using each of these as well as making multiple changes in one request:
197
164
@@ -200,31 +167,26 @@ Here are examples of using each of these as well as making multiple changes in o
200- [%mut](/docs/arvo/clay/examples#mut)
167- [%mut](/docs/arvo/clay/examples#mut)
201- [Multiple Changes](/docs/arvo/clay/examples#multiple-changes)
168- [Multiple Changes](/docs/arvo/clay/examples#multiple-changes)
202
169
203−
204−# Manage Mounts
170+## Manage Mounts
205
171
206Here we'll look at managing Clay unix mounts programmatically.
172Here we'll look at managing Clay unix mounts programmatically.
207
173
208There are four Clay `task`s relevant to mounts:
174There are four Clay `task`s relevant to mounts:
209
175
210−- [%boat](#boat) - List mounts.
176+- [%boat](#boat---list-mounts) - List mounts.
211−- [%mont](#mont) - Mount something.
177+- [%mont](#mont---mount) - Mount something.
212−- [%ogre](#ogre) - Unmount something.
178+- [%ogre](#ogre---unmount) - Unmount something.
213−- [%dirk](#dirk) - Commit changes.
179+- [%dirk](#dirk---commit) - Commit changes.
214−
215−## `%boat`
216−
217−A `%boat` `task` requests the list of existing mounts.
218
180
219−### Accepts
181+### `%boat` - List mounts
220
182
221```hoon
183```hoon
222−~
184+[%boat ~]
223```
185```
224
186
225−A `%boat` `task` does not take any arguments.
187+A `%boat` `task` requests the list of existing mounts and does not take any arguments.
226
188
227−### Returns
189+#### Returns
228
190
229The type it returns is a `%hill` `gift`, which looks like:
191The type it returns is a `%hill` `gift`, which looks like:
230
192
@@ -234,21 +196,18 @@ The type it returns is a `%hill` `gift`, which looks like:
234
196
235...where the `@tas` is the name of the mount point.
197...where the `@tas` is the name of the mount point.
236
198
237−### Example
199+#### Example
238
200
239[See here for an example of using %boat.](/docs/arvo/clay/examples#boat)
201[See here for an example of using %boat.](/docs/arvo/clay/examples#boat)
240
202
241−## `%mont`
203+### `%mont` - Mount
242−
243−
244−A `%mont` `task` mounts the specified `beam` to the specified `term` mount point.
245−
246−### Accepts
247
204
248```hoon
205```hoon
249−[pot=term bem=beam]
206+[%mont pot=term bem=beam]
250```
207```
251
208
209+A `%mont` `task` mounts the specified `beam` to the specified `term` mount point.
210+
252A `beam:clay` is the following structure:
211A `beam:clay` is the following structure:
253
212
254```hoon
213```hoon
@@ -257,73 +216,69 @@ A `beam:clay` is the following structure:
257
216
258You can mount the whole desk with a `path` of `/`, and you can also mount subdirectories or even individual files. If you want to mount an individual file, you must exclude its `mark` from the path. For example, if you want to mount `/gen/hood/hi/hoon`, you'd specify `/gen/hood/hi`. It will automatically be given the correct file extension when mounted. If you include the `hoon` mark it will crash (and currently crash your ship).
217You can mount the whole desk with a `path` of `/`, and you can also mount subdirectories or even individual files. If you want to mount an individual file, you must exclude its `mark` from the path. For example, if you want to mount `/gen/hood/hi/hoon`, you'd specify `/gen/hood/hi`. It will automatically be given the correct file extension when mounted. If you include the `hoon` mark it will crash (and currently crash your ship).
259
218
260−### Returns
219+#### Returns
261
220
262Clay does not return a `gift` in response to a `%mont` `%task`.
221Clay does not return a `gift` in response to a `%mont` `%task`.
263
222
264−### Example
223+#### Example
265
224
266[See here for an example of using %mont.](/docs/arvo/clay/examples#mont)
225[See here for an example of using %mont.](/docs/arvo/clay/examples#mont)
267
226
268−## `%ogre`
227+### `%ogre` - Unmount
269−
270−A `%ogre` `task` unmounts the specified mount.
271−
272−### Accepts
273
228
274```hoon
229```hoon
275−[pot=$@(desk beam)]
230+[%ogre pot=$@(desk beam)]
276```
231```
277
232
233+A `%ogre` `task` unmounts the specified mount.
234+
278It's defined in `lull.hoon` as taking `$@(desk beam)` but in fact it will only unmount the target when specified as a `term` mount name. Passing it a `desk` will incidentally work if the mount is named the same as the `desk` but otherwise it won't work. Passing it a `beam:clay` will simply not work.
235It's defined in `lull.hoon` as taking `$@(desk beam)` but in fact it will only unmount the target when specified as a `term` mount name. Passing it a `desk` will incidentally work if the mount is named the same as the `desk` but otherwise it won't work. Passing it a `beam:clay` will simply not work.
279
236
280−### Returns
237+#### Returns
281
238
282Clay does not return a `gift` in response to a `%ogre` `task`.
239Clay does not return a `gift` in response to a `%ogre` `task`.
283
240
284−### Example
241+#### Example
285
242
286[See here for an example of using %ogre.](/docs/arvo/clay/examples#ogre)
243[See here for an example of using %ogre.](/docs/arvo/clay/examples#ogre)
287
244
288−## `%dirk`
245+### `%dirk` - Commit
289−
290−A `%dirk` `task` commits changes in the target mount.
291−
292−### Accepts
293
246
294```hoon
247```hoon
295−des=desk
248+[%dirk des=desk]
296```
249```
297
250
251+A `%dirk` `task` commits changes in the target mount.
252+
298−It's defined in `lull.hoon` as taking a `desk` but like [%ogre](#ogre), it actually takes the name of a mount point rather than a `desk` as is specified.
253+It's defined in `lull.hoon` as taking a `desk` but like [%ogre](#ogre---unmount), it actually takes the name of a mount point rather than a `desk` as is specified.
299
254
300−### Returns
255+#### Returns
301
256
302Clay does not return a `gift` in response to a `%dirk` `task`.
257Clay does not return a `gift` in response to a `%dirk` `task`.
303
258
304−### Example
259+#### Example
305
260
306[See here for an example of using %dirk.](/docs/arvo/clay/examples#dirk)
261[See here for an example of using %dirk.](/docs/arvo/clay/examples#dirk)
307
262
308−# Merge Desks
263+## Merge Desks
309
264
310−## `%merg`
265+### `%merg` - Merge
311−
312−A `%merg` `task` will merge the specified source `desk` into the target local `desk`.
313−
314−### Accepts
315
266
316```hoon
267```hoon
268+$: %merg
317−$: des=desk :: target
269+ des=desk :: target
318 her=@p dem=desk cas=case :: source
270 her=@p dem=desk cas=case :: source
319 how=germ :: method
271 how=germ :: method
320==
272==
321```
273```
274+
275+A `%merg` `task` will merge the specified source `desk` into the target local `desk`.
276+
322The `germ` specifies the merge strategy. You can refer to the [Strategies](/docs/arvo/clay/using#strategies) section of the [Using Clay](/docs/arvo/clay/using) document for details of each `germ`.
277The `germ` specifies the merge strategy. You can refer to the [Strategies](/docs/arvo/clay/using#strategies) section of the [Using Clay](/docs/arvo/clay/using) document for details of each `germ`.
323
278
324If you're merging into a new `desk` you must use `%init`, all other strategies will fail. If the desk already exists, you cannot use `%init`. Otherwise, you're free to use whichever you'd like.
279If you're merging into a new `desk` you must use `%init`, all other strategies will fail. If the desk already exists, you cannot use `%init`. Otherwise, you're free to use whichever you'd like.
325
280
326−### Returns
281+#### Returns
327
282
328Clay will respond to the request with a `%mere` `gift` which looks like:
283Clay will respond to the request with a `%mere` `gift` which looks like:
329
284
@@ -344,15 +299,15 @@ If the merge failed, `p` will have a head of `%.n` and then a `[term tang]` wher
344]
299]
345```
300```
346
301
347−### Example
302+#### Example
348
303
349[See here for an example of using %merg.](/docs/arvo/clay/examples#merg)
304[See here for an example of using %merg.](/docs/arvo/clay/examples#merg)
350
305
351−# Permissions
306+## Permissions
352
307
353For each file or directory, there is both a read permission and a write permission. Each may be set separately and is either a whitelist or a blacklist (but not both). The whitelist/blacklist contains a `set` of ships and/or groups which are allowed or banned respectively. If it's an empty whitelist it means all foreign ships are denied. If it's an empty blacklist it means all foreign ships are allowed.
308For each file or directory, there is both a read permission and a write permission. Each may be set separately and is either a whitelist or a blacklist (but not both). The whitelist/blacklist contains a `set` of ships and/or groups which are allowed or banned respectively. If it's an empty whitelist it means all foreign ships are denied. If it's an empty blacklist it means all foreign ships are allowed.
354
309
355−If permissions are not set for a particular file, they will be inherited from the directory in which it resides. If *that* directory has no permissions set, they will be inherited from another level up, and so on to the `desk`'s root directory. If the root directory has no permissions set, it will have the default permissions of an empty whitelist, meaning "deny all".
310+If permissions are not set for a particular file, they will be inherited from the directory in which it resides. If _that_ directory has no permissions set, they will be inherited from another level up, and so on to the `desk`'s root directory. If the root directory has no permissions set, it will have the default permissions of an empty whitelist, meaning "deny all".
356
311
357A group is called a `crew` and is just a `set` of ships with a `@ta` name.
312A group is called a `crew` and is just a `set` of ships with a `@ta` name.
358
313
@@ -390,18 +345,16 @@ A `%perm` `task` is for setting permissions, and the other three are for managin
390
345
391We'll look at each of these in turn.
346We'll look at each of these in turn.
392
347
393−## `%perm`
348+### `%perm` - Set perms
349+
350+```hoon
351+[%perm des=desk pax=path rit=rite]
352+```
394
353
395A `%perm` `task` sets permissions for the target file or directory.
354A `%perm` `task` sets permissions for the target file or directory.
396
355
397Note this will replace existing permissions rather than add to them, so if you want to add a ship to an existing whitelist or whatever you'll have to first read the existing permissions, add the ship, then send the whole lot back.
356Note this will replace existing permissions rather than add to them, so if you want to add a ship to an existing whitelist or whatever you'll have to first read the existing permissions, add the ship, then send the whole lot back.
398
357
399−### Accepts
400−
401−```hoon
402−[des=desk pax=path rit=rite]
403−```
404−
405The `pax` path is the file or directory whose permissions you want to change, and the `rite` is this structure:
358The `pax` path is the file or directory whose permissions you want to change, and the `rite` is this structure:
406
359
407```hoon
360```hoon
@@ -409,6 +362,7 @@ The `pax` path is the file or directory whose permissions you want to change, an
409 $% [%r red=(unit rule)] :: for read
362 $% [%r red=(unit rule)] :: for read
410 [%w wit=(unit rule)] :: for write
363 [%w wit=(unit rule)] :: for write
411 [%rw red=(unit rule) wit=(unit rule)] :: for read and write
364 [%rw red=(unit rule) wit=(unit rule)] :: for read and write
365+ ==
412```
366```
413
367
414Where a `rule` is this structure:
368Where a `rule` is this structure:
@@ -425,51 +379,47 @@ Where a `rule` is this structure:
425
379
426As the comment suggests, the `@ta` is the name of a `crew` (group).
380As the comment suggests, the `@ta` is the name of a `crew` (group).
427
381
428−### Returns
382+#### Returns
429
383
430Clay does not return a `gift` in response to a `%perm` `task`.
384Clay does not return a `gift` in response to a `%perm` `task`.
431
385
432−### Example
386+#### Example
433
387
434[See here for an example of using %perm.](/docs/arvo/clay/examples#perm)
388[See here for an example of using %perm.](/docs/arvo/clay/examples#perm)
435
389
436−## `%cred`
390+### `%cred` - Add group
437−
438−This simply creates a permission group.
439−
440−### Accepts
441
391
442```hoon
392```hoon
443−[nom=@ta cew=crew]
393+[%cred nom=@ta cew=crew]
444```
394```
445
395
396+This simply creates a permission group.
397+
446The `nom` is a name for the group and the `crew` is just a `(set ship)`:
398The `nom` is a name for the group and the `crew` is just a `(set ship)`:
447
399
448```hoon
400```hoon
449+$ crew (set ship) :: permissions group
401+$ crew (set ship) :: permissions group
450```
402```
451
403
452−### Returns
404+#### Returns
453
405
454Clay does not return a `gift` in response to a `%cred` `task`.
406Clay does not return a `gift` in response to a `%cred` `task`.
455
407
456−### Example
408+#### Example
457
409
458[See here for an example of using %cred.](/docs/arvo/clay/examples#cred)
410[See here for an example of using %cred.](/docs/arvo/clay/examples#cred)
459
411
460−## `%crew`
412+### `%crew` - Get groups
461−
462−This retrieves all permission groups.
463−
464−### Accepts
465
413
466```hoon
414```hoon
467−~
415+[%crew ~]
468```
416```
469
417
418+This retrieves all permission groups.
419+
470A `%crew` `task` takes no arguments.
420A `%crew` `task` takes no arguments.
471
421
472−### Returns
422+#### Returns
473
423
474Clay wil return a `%cruz` `gift`. It looks like:
424Clay wil return a `%cruz` `gift`. It looks like:
475
425
@@ -479,23 +429,21 @@ Clay wil return a `%cruz` `gift`. It looks like:
479
429
480The `cez` is just a map from group name to `crew` which is just a `(set ship)`.
430The `cez` is just a map from group name to `crew` which is just a `(set ship)`.
481
431
482−### Example
432+#### Example
483
433
484[See here for an example of using %crew.](/docs/arvo/clay/examples#crew)
434[See here for an example of using %crew.](/docs/arvo/clay/examples#crew)
485
435
486−## `%crow`
436+### `%crow` - Group files
487−
488−A `%crow` `task` retrieves all files and directories in all `desk`s which have permissions set for the group in question. It will not return inherited permissions, only those explicitly set.
489−
490−### Accepts
491
437
492```hoon
438```hoon
493−nom=@ta
439+[%crow nom=@ta]
494```
440```
495
441
442+A `%crow` `task` retrieves all files and directories in all `desk`s which have permissions set for the group in question. It will not return inherited permissions, only those explicitly set.
443+
496The `nom` is the name of a `crew`.
444The `nom` is the name of a `crew`.
497
445
498−### Returns
446+#### Returns
499
447
500The `gift` you get back is a `%croz` which looks like:
448The `gift` you get back is a `%croz` which looks like:
501
449
@@ -509,19 +457,19 @@ The `gift` you get back is a `%croz` which looks like:
509+$ regs (map path rule) :: rules for paths
457+$ regs (map path rule) :: rules for paths
510```
458```
511
459
512−### Example
460+#### Example
513
461
514[See here for an example of using %crow.](/docs/arvo/clay/examples#crow)
462[See here for an example of using %crow.](/docs/arvo/clay/examples#crow)
515
463
516−# Foreign Ships
464+## Foreign Ships
517
465
518Here we'll looking at making Clay requests to a foreign ship.
466Here we'll looking at making Clay requests to a foreign ship.
519
467
520As it currently stands, it's not possible to write to a foreign `desk`. Additionally, remote scries are not implemented. That leaves requests to read files (`%warp`) and merge desks (`%merg`), which we'll look at next.
468As it currently stands, it's not possible to write to a foreign `desk`. Additionally, remote scries are not implemented. That leaves requests to read files (`%warp`) and merge desks (`%merg`), which we'll look at next.
521
469
522−## `%warp` - Remote
470+### `%warp` - Remote
523
471
524−To read files on a foreign `desk`, you just send Clay a `%warp` `task` (as you would for a local read) and specify the target ship in the `wer` field. For details on making such requests, see the [Read and Subscribe](#warp) section.
472+To read files on a foreign `desk`, you just send Clay a `%warp` `task` (as you would for a local read) and specify the target ship in the `wer` field. For details on making such requests, see the [Read and Subscribe](#warp---read-and-track) section.
525
473
526Clay only allows a subset of `care`s to be used remotely. They are:
474Clay only allows a subset of `care`s to be used remotely. They are:
527
475
@@ -538,11 +486,11 @@ The foreign ship will respond only if correct permissions have been set. See the
538
486
539Note that if you're reading a whole `desk` or directory, all subfolders and files must also permit reading. If even a single file does not permit you reading it, the foreign ship will not respond to the request.
487Note that if you're reading a whole `desk` or directory, all subfolders and files must also permit reading. If even a single file does not permit you reading it, the foreign ship will not respond to the request.
540
488
541−### Example
489+#### Example
542
490
543[See here for examples of requests to foreign ships.](/docs/arvo/clay/examples#foreign-ships)
491[See here for examples of requests to foreign ships.](/docs/arvo/clay/examples#foreign-ships)
544
492
545−## `%merg` - Remote
493+### `%merg` - Remote
546
494
547To merge a foreign `desk` into a local one, you just send Clay a `%merg` `task` (as you would for a local merge) and specify the foreign ship in the `her` field. For details on making such requests, see the [Merge Desks](#merge-desks) section.
495To merge a foreign `desk` into a local one, you just send Clay a `%merg` `task` (as you would for a local merge) and specify the foreign ship in the `her` field. For details on making such requests, see the [Merge Desks](#merge-desks) section.
548
496
@@ -550,6 +498,6 @@ The foreign ship will respond only if correct permissions have been set. See the
550
498
551Note that all subfolders and individual files within the `desk` must permit your reading in order for the merge to succeed. If even one file does not permit you reading it, the remote ship will not respond to the request at all.
499Note that all subfolders and individual files within the `desk` must permit your reading in order for the merge to succeed. If even one file does not permit you reading it, the remote ship will not respond to the request at all.
552
500
553−### Example
501+#### Example
554
502
555[See here for examples of requests to foreign ships.](/docs/arvo/clay/examples#foreign-ships)
503[See here for examples of requests to foreign ships.](/docs/arvo/clay/examples#foreign-ships)