further small docs fixes

docs/1.2/app_developers_guide/creating_sawtooth_network.md

@@ -376,6 +376,13 @@ running.
     > MyKey: 999
     > ```
 
+> **Note**
+>
+> One may create a [`cli.toml` file](../sysadmin_guide/configuring_sawtooth#sawtooth-cli-configuration-file)
+> (and perhaps [set `SAWTOOTH_HOME`](../sysadmin_guide/configuring_sawtooth#path-configuration-file))
+> to set a new default URL for some of the CLI commands, like
+> `sawtooth peer list`. Others, like `intkey`, may still need a `--url` to be given.
+
 ### Step 5. Configure the Allowed Transaction Types (Optional) {#configure-txn-procs-docker-label}
 
 By default, a validator accepts transactions from any transaction

docs/1.2/app_developers_guide/installing_sawtooth.md

@@ -2112,9 +2112,8 @@ beginning of this procedure, add these steps:
 -   To delete the Sawtooth logs, remove all files from
     `/var/log/sawtooth/`.
 -   To delete the Sawtooth keys, remove the key files
-    `/etc/sawtooth/keys/validator.\*` and
-    `/home/`*yourname*`/.sawtooth/keys/`*yourname*`.\*`.
-
+    `/etc/sawtooth/keys/validator.*` and
+    `/home/`*yourname*`/.sawtooth/keys/`*yourname*`.*`.
 
 <!--
   Licensed under Creative Commons Attribution 4.0 International License

docs/1.2/cli/sawnet.md

@@ -138,8 +138,10 @@ optional arguments:
 
 ## sawnet peers graph
 
-The `sawnet peers graph` subcommand displays a file called `peers.dot`
-that describes the peering arrangement of the specified nodes.
+The `sawnet peers graph` subcommand creates a file called `peers.dot`
+that describes the peering arrangement of the specified nodes. The
+[Graphviz documentation](https://www.graphviz.org/documentation/) describes
+the file format and how to transform it into a diagram.
 
 ```console
 usage: sawnet peers graph [-h] [-v] [-V] [--users USERNAME[:PASSWORD]]

docs/1.2/cli/sawtooth.md

@@ -66,7 +66,7 @@ The `sawtooth batch` subcommands display information about the Batches
 in the current blockchain and submit Batches to the validator via the
 REST API. A Batch is a group of interdependent transactions that is the
 atomic unit of change in Sawtooth. For more information, see
-"Transactions and Batches!"
+[Transactions and Batches](../architecture/transactions_and_batches).
 
 ```console
 usage: sawtooth batch [-h] {list,show,status,submit} ...
@@ -321,7 +321,7 @@ the current roles and policy set in state, create new roles, and new
 policies.
 
 Note that only the public keys stored in the setting
-sawtooth.identity.allowed_keys are allowed to submit identity
+`sawtooth.identity.allowed_keys` are allowed to submit identity
 transactions. Use the `sawset` commands to change this setting.
 
 ```console
@@ -678,10 +678,6 @@ This subcommand requires the URL of the REST API (default:
 `username`:`password` combination when the REST API is
 behind a Basic Auth proxy.
 
-By default, the peers are displayed as a CSV string, but other
-plain-text formats (JSON, and YAML) are available and can be piped into
-a file for further processing.
-
 ```console
 usage: sawtooth state show [-h] [--url URL] [-u USERNAME[:PASSWORD]]
                            [--head HEAD]
@@ -729,6 +725,10 @@ This subcommand requires the URL of the REST API (default:
 `username`:`password` combination when the REST API is
 behind a Basic Auth proxy.
 
+By default, the status is displayed as a CSV string, but other
+plain-text formats (JSON, and YAML) are available and can be piped into
+a file for further processing.
+
 ```console
 usage: sawtooth status show [-h] [--url URL] [-u USERNAME[:PASSWORD]]
                             [-F {csv,json,yaml,default}]

docs/1.2/cli/xo.md

@@ -28,7 +28,7 @@ submission of transactions to a running validator via the URL of the
 validator\'s REST API.
 
 Before playing a game, you must start a validator, the XO transaction
-processor,and the REST API. The XO client sends requests to update and
+processor, and the REST API. The XO client sends requests to update and
 query the blockchain to the URL of the REST API (by default,
 `http://127.0.0.1:8008`).
 

docs/1.2/pbft/architecture.md

@@ -146,7 +146,7 @@ network are able to participate in the consensus process.
 Any messages that fail to parse or pass the required checks are ignored.  If a
 message is successfully parsed and passes verification, it is passed to a
 handler for that specific message type (see [Message
-Types]#pbft-arch-message-types)), where it may go through further checks, be
+Types](#pbft-arch-message-types)), where it may go through further checks, be
 stored in the message log, or trigger some actions.
 
 ### Message Definitions

docs/1.2/pbft/configuring-pbft.md

@@ -76,7 +76,7 @@ processor]({% link
 docs/1.2/transaction_family_specifications/settings_transaction_family.md %})
 (or an equivalent) is required to process these settings.
 
-> ** Tip **
+> **Tip**
 >
 > To display the existing settings, use [sawtooth settings
 > list]({% link docs/1.2/cli/sawtooth.md %}#sawtooth-settings-list).

docs/1.2/pbft/installing-and-running-pbft.md

@@ -21,7 +21,7 @@ installed.
    $ docker run -v $(pwd):/project/sawtooth-pbft -it sawtooth-dev-pbft bash
     ```
 
-   > *Tip*
+   > **Tip**
    >
    > If you have already configured a `cargo-registry` Docker volume, use the
    > following `docker run` command to speed up the build time in the next step.

docs/1.2/sabre/application_developer_guide.md

@@ -231,13 +231,13 @@ pub unsafe fn entrypoint(payload: WasmPtr, signer: WasmPtr, signature: WasmPtr)
 > Wasm. This may improve over time as Wasm popularity grows, or it may
 > persist into the future.
 >
-> For example, cbor-codec, cbor crate used in the intkey transaction
+> For example, cbor-codec, the cbor crate used in the intkey transaction
 > processor, does not compile into wasm and serde_cbor is missing libm
 > dependencies at runtime. To bypass this, custom intkey cbor encode and
 > decode functions had to be written for intkey multiply.
 
 For the full intkey-multiply example look at
-sawtooth-sabre/example/intkey_multiply/processor
+[`sawtooth-sabre/example/intkey_multiply/processor`](https://github.com/hyperledger/sawtooth-sabre/tree/main/example/intkey_multiply/processor).
 
 ## Logging in a Sabre Smart Contract {#logging-in-smart-contracts}
 
@@ -281,7 +281,7 @@ fn apply(
 
 The log level of the Sabre transaction processor is enforced for all
 smart contracts. For example, if the Sabre transaction processor has a
-log level of `info` a `debug` statement in a smart contract will not be
+log level of `info` then a `debug` statement in a smart contract will not be
 logged.
 
 ## Compiling the Contract {#compiling-smart-contract-label}
@@ -298,7 +298,7 @@ $ rustup target add wasm32-unknown-unknown --toolchain nightly
 ```
 
 To compile the smart contract run the following command in
-sawtooth-sabre/example/intkey_multiply/processor:
+`sawtooth-sabre/example/intkey_multiply/processor`:
 
 ```console
 $ cargo build --target wasm32-unknown-unknown --release
@@ -313,7 +313,7 @@ $ cargo build --target wasm32-unknown-unknown --release
 > -   Compile in Release mode (`--release`)
 > -   Remove any `"{:?}"` from any format strings, as this pulls in a
 >     bunch of stuff
-> -   Use this script to reduce the size
+> -   Use this script to reduce the size:
 >     <https://www.hellorust.com/news/native-wasm-target.html>
 
 ### AssemblyScript
@@ -463,7 +463,7 @@ IntegerKey (intkey), and Sabre.
 In this step, you will use the `sabre-shell` container to set initial
 values in state for your contract.
 
-The `intkey-multiply` smart contract executes the simple function `A=B\*C`. This
+The `intkey-multiply` smart contract executes the simple function `A=B*C`. This
 contract requires existing `B` and `C` values from state, then stores the result
 `A` in state. This example also requires a payload file that identifies these
 values by key name.

docs/1.2/sabre/sabre_cli.md

@@ -14,7 +14,7 @@ registries and their permissions.
 `sabre` is the top level command for Sabre. It contains the following
 subcommands: `cr`, `upload`, `ns`, `perm`, and `exec`. The subcommands
 have options and arguments that control their behavior. All subcommands
-include `-key`, the name of the signing key, and `--url`, the url to the
+include `--key`, the name of the signing key, and `--url`, the url to the
 Sawtooth REST API.
 
 ```
@@ -228,7 +228,7 @@ should be a path to the file that contains the Sabre contract bytes.
 
 ## sabre sp
 
-The `sabre sp` subbcommand submits a Sabre transaction that can create,
+The `sabre sp` subcommand submits a Sabre transaction that can create,
 update, or delete smart permissions
 
 ```

docs/1.2/sabre/sabre_transaction_family.md

@@ -94,7 +94,7 @@ message ContractRegistry {
 ```
 
 ContractRegistry entries whose addresses collide are stored in a
-ContractRegsitryList.
+ContractRegistryList.
 
 ```protobuf
 message ContractRegistryList {

docs/1.2/sabre/version_compatibility.md

@@ -40,9 +40,9 @@ the Docker tag for the Sabre transaction processor image.
     <td>
         <ul>
             <li>Transaction context is a trait</li>
-            <li>API has new `get_state_entry` to get one entry and
-                `get_state_entries` to get multiple entries (plus corresponding
-                functions for set and delete)</li>
+            <li>API has new <code>get_state_entry</code> to get one entry and
+                <code>get_state_entries</code> to get multiple entries
+                (plus corresponding functions for set and delete)</li>
         </ul>
     </td>
 </tr>

docs/1.2/sysadmin_guide/configuring_sawtooth.md

@@ -288,7 +288,7 @@ file.
 > **Note**
 >
 > By default, the config directory is `/etc/sawtooth/`.
-> See [Path Configuration File](#path-configuration_file) for more information.
+> See [Path Configuration File](#path-configuration-file) for more information.
 
 An example configuration file is in the `sawtooth-core` repository at
 `/sawtooth-core/rest_api/packaging/rest_api.toml.example`. To create a
@@ -369,7 +369,7 @@ configuration file.
 > **Note**
 >
 > By default, the config directory is `/etc/sawtooth/`.
-> See [Path Configuration File](#path-configuration_file) for more information.
+> See [Path Configuration File](#path-configuration-file) for more information.
 
 An example configuration file is in the `sawtooth-core` repository at
 `/sawtooth-core/cli/cli.toml.example`. To create a CLI configuration
@@ -400,7 +400,7 @@ configuration file.
 > **Note**
 >
 > By default, the config directory is `/etc/sawtooth/`.
-> See [Path Configuration File](#path-configuration_file) for more information.
+> See [Path Configuration File](#path-configuration-file) for more information.
 
 An example configuration file is in the `sawtooth-core` repository at
 `/sawtooth-core/consensus/poet/sgx/packaging/poet_enclave_sgx.toml.example`.
@@ -472,7 +472,7 @@ the configuration file.
 > **Note**
 >
 > By default, the config directory is `/etc/sawtooth/`.
-> See [Path Configuration File](#path-configuration_file) for more information.
+> See [Path Configuration File](#path-configuration-file) for more information.
 
 An example configuration file is in the `sawtooth-core` repository at
 `/sawtooth-core/families/identity/sawtooth_identity/packaging/identity.toml.example`.
@@ -506,7 +506,7 @@ the configuration file.
 > **Note**
 >
 > By default, the config directory is `/etc/sawtooth/`.
-> See [Path Configuration File](#path-configuration_file) for more information.
+> See [Path Configuration File](#path-configuration-file) for more information.
 
 An example configuration file is in the `sawtooth-core` repository at
 `/sawtooth-core/families/settings/packaging/settings.toml.example`. To
@@ -540,7 +540,7 @@ the configuration file.
 > **Note**
 >
 > By default, the config directory is `/etc/sawtooth/`.
-> See [Path Configuration File](#path-configuration_file) for more information.
+> See [Path Configuration File](#path-configuration-file) for more information.
 
 An example configuration file is in the `sawtooth-sdk-python` repository
 at

faq/settings.md

@@ -71,7 +71,10 @@ sawtooth.consensus.pbft.members
 :   JSON list of public keys belonging to each node that is a member of
     the PBFT network. Only required PBFT setting. Key is from
     `/etc/sawtooth/keys/validator.pub` . Example:
-    `["0276f8fed116837eb7646f800e2dad6d13ad707055923e49df08f47a963547b631",\ "035d8d519a200cdb8085c62d6fb9f2678cf71cbde738101d61c4c8c2e9f2919aa"]`
+    ```json
+    ["0276f8fed116837eb7646f800e2dad6d13ad707055923e49df08f47a963547b631",
+     "035d8d519a200cdb8085c62d6fb9f2678cf71cbde738101d61c4c8c2e9f2919aa3"]
+    ```
 
     For details on this and other PBFT settings, see
     <https://github.com/hyperledger/sawtooth-pbft/blob/master/src/config.rs>
@@ -115,7 +118,10 @@ sawtooth.consensus.raft.peers
 
 :   JSON list of each peer node\'s public key. Only required RAFT
     setting. Key is from `/etc/sawtooth/keys/validator.pub` . Example:
-    `["0276f8fed116837eb7646f800e2dad6d13ad707055923e49df08f47a963547b631",\ "035d8d519a200cdb8085c62d6fb9f2678cf71cbde738101d61c4c8c2e9f2919aa"]`
+    ```json
+    ["0276f8fed116837eb7646f800e2dad6d13ad707055923e49df08f47a963547b631",\
+     "035d8d519a200cdb8085c62d6fb9f2678cf71cbde738101d61c4c8c2e9f2919aa3"]
+    ```
 
 sawtooth.consensus.raft.period
 

faq/transaction-processing.md

@@ -365,7 +365,7 @@ all the supported transaction families in this Sawtooth blockchain network.
 
 One way is to add logging messages (using`LOGGER.info()` for Python or Rust
 log4rs). and sprinkle your code with debug messages, such as
-`LOGGER.info(\"Action = %s.\", action)]` in
+`LOGGER.info("Action = %s.", action)]` in
 Python (or another language you use for the TP). Start the transaction
 processor with the `-vv` or `-vvv` flags and look for console output.