Fossil SCM
Various minor documentation enhancements.
Commit
787466468d4ebf99c3c486446e770f9de34a521f8a90a0cc2a76162992639522
Parent
35ad8eca06ffad0…
3 files changed
+2
-2
+4
-2
+3
-3
+2
-2
| --- www/customskin.md | ||
| +++ www/customskin.md | ||
| @@ -216,14 +216,14 @@ | ||
| 216 | 216 | ### Skin Development Using The Web Interface |
| 217 | 217 | |
| 218 | 218 | Users with admin privileges can use the Admin/Skin configuration page |
| 219 | 219 | on the web interface to develop a new skin. The development of a new |
| 220 | 220 | skin occurs without disrupting the existing skin. So you can work on |
| 221 | -a new skin for a Fossil instance will the existing skin is still in | |
| 221 | +a new skin for a Fossil instance while the existing skin is still in | |
| 222 | 222 | active use. |
| 223 | 223 | |
| 224 | -The new skins is "draft" skin. You initialize one of 9 draft skins | |
| 224 | +The new skin is a "draft" skin. You initialize one of 9 draft skins | |
| 225 | 225 | to either the current skin or to one of the built-in skins. Then |
| 226 | 226 | use forms to edit the 5 control files described above. The new |
| 227 | 227 | skin can be tested after each edit. Finally, once the new skin is |
| 228 | 228 | working as desired, the draft skin is "published" and becomes the |
| 229 | 229 | new live skin that most users see. |
| 230 | 230 |
| --- www/customskin.md | |
| +++ www/customskin.md | |
| @@ -216,14 +216,14 @@ | |
| 216 | ### Skin Development Using The Web Interface |
| 217 | |
| 218 | Users with admin privileges can use the Admin/Skin configuration page |
| 219 | on the web interface to develop a new skin. The development of a new |
| 220 | skin occurs without disrupting the existing skin. So you can work on |
| 221 | a new skin for a Fossil instance will the existing skin is still in |
| 222 | active use. |
| 223 | |
| 224 | The new skins is "draft" skin. You initialize one of 9 draft skins |
| 225 | to either the current skin or to one of the built-in skins. Then |
| 226 | use forms to edit the 5 control files described above. The new |
| 227 | skin can be tested after each edit. Finally, once the new skin is |
| 228 | working as desired, the draft skin is "published" and becomes the |
| 229 | new live skin that most users see. |
| 230 |
| --- www/customskin.md | |
| +++ www/customskin.md | |
| @@ -216,14 +216,14 @@ | |
| 216 | ### Skin Development Using The Web Interface |
| 217 | |
| 218 | Users with admin privileges can use the Admin/Skin configuration page |
| 219 | on the web interface to develop a new skin. The development of a new |
| 220 | skin occurs without disrupting the existing skin. So you can work on |
| 221 | a new skin for a Fossil instance while the existing skin is still in |
| 222 | active use. |
| 223 | |
| 224 | The new skin is a "draft" skin. You initialize one of 9 draft skins |
| 225 | to either the current skin or to one of the built-in skins. Then |
| 226 | use forms to edit the 5 control files described above. The new |
| 227 | skin can be tested after each edit. Finally, once the new skin is |
| 228 | working as desired, the draft skin is "published" and becomes the |
| 229 | new live skin that most users see. |
| 230 |
+4
-2
| --- www/serverext.wiki | ||
| +++ www/serverext.wiki | ||
| @@ -203,10 +203,12 @@ | ||
| 203 | 203 | <script nonce='$FOSSIL_NONCE'>...</script> |
| 204 | 204 | </verbatim></blockquote> |
| 205 | 205 | |
| 206 | 206 | Except, of course, the $FOSSIL_NONCE is replaced by the value of the |
| 207 | 207 | FOSSIL_NONCE environment variable. |
| 208 | + | |
| 209 | +<h3>3.1 Input Content</h3> | |
| 208 | 210 | |
| 209 | 211 | If the HTTP request includes content (for example if this is a POST request) |
| 210 | 212 | then the CONTENT_LENGTH value will be positive and the data for the content |
| 211 | 213 | will be readable on standard input. |
| 212 | 214 | |
| @@ -277,12 +279,12 @@ | ||
| 277 | 279 | <h2>6.0 Trouble-Shooting Hints</h2> |
| 278 | 280 | |
| 279 | 281 | Remember that the /ext will return any file in the extroot directory |
| 280 | 282 | hierarchy as static content if the file is readable but not executable. |
| 281 | 283 | When initially setting up the /ext mechanism, it is sometimes helpful |
| 282 | -to verify that you are able to receive static content prior to working | |
| 283 | -on getting your CGIs working. Also remember that CGIs must be | |
| 284 | +to verify that you are able to receive static content prior to starting | |
| 285 | +work on your CGIs. Also remember that CGIs must be | |
| 284 | 286 | executable files. |
| 285 | 287 | |
| 286 | 288 | Fossil likes to run inside a chroot jail, and will automatically put |
| 287 | 289 | itself inside a chroot jail if it can. The sub-CGI program will also |
| 288 | 290 | run inside this same chroot jail. Make sure all embedded pathnames |
| 289 | 291 |
| --- www/serverext.wiki | |
| +++ www/serverext.wiki | |
| @@ -203,10 +203,12 @@ | |
| 203 | <script nonce='$FOSSIL_NONCE'>...</script> |
| 204 | </verbatim></blockquote> |
| 205 | |
| 206 | Except, of course, the $FOSSIL_NONCE is replaced by the value of the |
| 207 | FOSSIL_NONCE environment variable. |
| 208 | |
| 209 | If the HTTP request includes content (for example if this is a POST request) |
| 210 | then the CONTENT_LENGTH value will be positive and the data for the content |
| 211 | will be readable on standard input. |
| 212 | |
| @@ -277,12 +279,12 @@ | |
| 277 | <h2>6.0 Trouble-Shooting Hints</h2> |
| 278 | |
| 279 | Remember that the /ext will return any file in the extroot directory |
| 280 | hierarchy as static content if the file is readable but not executable. |
| 281 | When initially setting up the /ext mechanism, it is sometimes helpful |
| 282 | to verify that you are able to receive static content prior to working |
| 283 | on getting your CGIs working. Also remember that CGIs must be |
| 284 | executable files. |
| 285 | |
| 286 | Fossil likes to run inside a chroot jail, and will automatically put |
| 287 | itself inside a chroot jail if it can. The sub-CGI program will also |
| 288 | run inside this same chroot jail. Make sure all embedded pathnames |
| 289 |
| --- www/serverext.wiki | |
| +++ www/serverext.wiki | |
| @@ -203,10 +203,12 @@ | |
| 203 | <script nonce='$FOSSIL_NONCE'>...</script> |
| 204 | </verbatim></blockquote> |
| 205 | |
| 206 | Except, of course, the $FOSSIL_NONCE is replaced by the value of the |
| 207 | FOSSIL_NONCE environment variable. |
| 208 | |
| 209 | <h3>3.1 Input Content</h3> |
| 210 | |
| 211 | If the HTTP request includes content (for example if this is a POST request) |
| 212 | then the CONTENT_LENGTH value will be positive and the data for the content |
| 213 | will be readable on standard input. |
| 214 | |
| @@ -277,12 +279,12 @@ | |
| 279 | <h2>6.0 Trouble-Shooting Hints</h2> |
| 280 | |
| 281 | Remember that the /ext will return any file in the extroot directory |
| 282 | hierarchy as static content if the file is readable but not executable. |
| 283 | When initially setting up the /ext mechanism, it is sometimes helpful |
| 284 | to verify that you are able to receive static content prior to starting |
| 285 | work on your CGIs. Also remember that CGIs must be |
| 286 | executable files. |
| 287 | |
| 288 | Fossil likes to run inside a chroot jail, and will automatically put |
| 289 | itself inside a chroot jail if it can. The sub-CGI program will also |
| 290 | run inside this same chroot jail. Make sure all embedded pathnames |
| 291 |
+3
-3
| --- www/th1.md | ||
| +++ www/th1.md | ||
| @@ -12,12 +12,12 @@ | ||
| 12 | 12 | time all of the test cases for SQLite were written in Tcl and Tcl could not |
| 13 | 13 | be easily compiled on the SymbianOS. So TH1 was developed as a cut-down |
| 14 | 14 | version of Tcl that would facilitate running the SQLite test scripts on |
| 15 | 15 | SymbianOS. |
| 16 | 16 | |
| 17 | -The testing of SQLite on SymbianOS was eventually accomplished by other | |
| 18 | -means. But Fossil was first being designed at about the same time. | |
| 17 | +Fossil was first being designed at about the same time that TH1 was | |
| 18 | +being developed for testing SQLite on SymbianOS. | |
| 19 | 19 | Early prototypes of Fossil were written in pure Tcl. But as the development |
| 20 | 20 | shifted toward the use of C-code, the need arose to have a Tcl-like |
| 21 | 21 | scripting language to help with code generation. TH1 was small and |
| 22 | 22 | light-weight and used minimal resources and seemed ideally suited for the |
| 23 | 23 | task. |
| @@ -41,11 +41,11 @@ | ||
| 41 | 41 | name and subsequent tokens are the arguments. In this sense, TH1 syntax |
| 42 | 42 | is similar to the familiar command-line shell syntax. |
| 43 | 43 | |
| 44 | 44 | A token is any sequence of characters other than whitespace and semicolons. |
| 45 | 45 | Or, all text without double-quotes is a single token even if it includes |
| 46 | -whitespace and semicolons. Or, all text without nested {...} pairs is a | |
| 46 | +whitespace and semicolons. Or, all text within nested {...} pairs is a | |
| 47 | 47 | single token. |
| 48 | 48 | |
| 49 | 49 | The nested {...} form of tokens is important because it allows TH1 commands |
| 50 | 50 | to have an appearance similar to C/C++. It is important to remember, though, |
| 51 | 51 | that a TH1 script is really just a list of text commands, not a context-free |
| 52 | 52 |
| --- www/th1.md | |
| +++ www/th1.md | |
| @@ -12,12 +12,12 @@ | |
| 12 | time all of the test cases for SQLite were written in Tcl and Tcl could not |
| 13 | be easily compiled on the SymbianOS. So TH1 was developed as a cut-down |
| 14 | version of Tcl that would facilitate running the SQLite test scripts on |
| 15 | SymbianOS. |
| 16 | |
| 17 | The testing of SQLite on SymbianOS was eventually accomplished by other |
| 18 | means. But Fossil was first being designed at about the same time. |
| 19 | Early prototypes of Fossil were written in pure Tcl. But as the development |
| 20 | shifted toward the use of C-code, the need arose to have a Tcl-like |
| 21 | scripting language to help with code generation. TH1 was small and |
| 22 | light-weight and used minimal resources and seemed ideally suited for the |
| 23 | task. |
| @@ -41,11 +41,11 @@ | |
| 41 | name and subsequent tokens are the arguments. In this sense, TH1 syntax |
| 42 | is similar to the familiar command-line shell syntax. |
| 43 | |
| 44 | A token is any sequence of characters other than whitespace and semicolons. |
| 45 | Or, all text without double-quotes is a single token even if it includes |
| 46 | whitespace and semicolons. Or, all text without nested {...} pairs is a |
| 47 | single token. |
| 48 | |
| 49 | The nested {...} form of tokens is important because it allows TH1 commands |
| 50 | to have an appearance similar to C/C++. It is important to remember, though, |
| 51 | that a TH1 script is really just a list of text commands, not a context-free |
| 52 |
| --- www/th1.md | |
| +++ www/th1.md | |
| @@ -12,12 +12,12 @@ | |
| 12 | time all of the test cases for SQLite were written in Tcl and Tcl could not |
| 13 | be easily compiled on the SymbianOS. So TH1 was developed as a cut-down |
| 14 | version of Tcl that would facilitate running the SQLite test scripts on |
| 15 | SymbianOS. |
| 16 | |
| 17 | Fossil was first being designed at about the same time that TH1 was |
| 18 | being developed for testing SQLite on SymbianOS. |
| 19 | Early prototypes of Fossil were written in pure Tcl. But as the development |
| 20 | shifted toward the use of C-code, the need arose to have a Tcl-like |
| 21 | scripting language to help with code generation. TH1 was small and |
| 22 | light-weight and used minimal resources and seemed ideally suited for the |
| 23 | task. |
| @@ -41,11 +41,11 @@ | |
| 41 | name and subsequent tokens are the arguments. In this sense, TH1 syntax |
| 42 | is similar to the familiar command-line shell syntax. |
| 43 | |
| 44 | A token is any sequence of characters other than whitespace and semicolons. |
| 45 | Or, all text without double-quotes is a single token even if it includes |
| 46 | whitespace and semicolons. Or, all text within nested {...} pairs is a |
| 47 | single token. |
| 48 | |
| 49 | The nested {...} form of tokens is important because it allows TH1 commands |
| 50 | to have an appearance similar to C/C++. It is important to remember, though, |
| 51 | that a TH1 script is really just a list of text commands, not a context-free |
| 52 |