Merge pull request #691 from hashicorp/sethvargo/tabs_spaces_oh_my

Remove tabs from terminal output

website/source/docs/auth/cert.html.md

@@ -21,7 +21,7 @@ from an external source.
 
 ### Via the CLI
 ```
-vault auth -method=cert \
+$ vault auth -method=cert \
     -ca-cert=ca.pem -client-cert=cert.pem -client-key=key.pem
 ```
 
@@ -31,7 +31,7 @@ certificate and when the login endpoint is hit, the auth backend will determine
 if there is a matching trusted certificate to authenticate the client.
 
 ```
-curl --cacert ca.pem --cert cert.pem --key key.pem \
+$ curl --cacert ca.pem --cert cert.pem --key key.pem \
     $VAULT_ADDR/v1/auth/cert/login -XPOST
 ```
 
@@ -57,7 +57,11 @@ trusted certificates that are allowed to authenticate. An example is shown below
 Use `vault path-help` for more details.
 
 ```
-$ vault write auth/cert/certs/web display_name=web policies=web,prod certificate=@web-cert.pem lease=3600
+$ vault write auth/cert/certs/web \
+    display_name=web \
+    policies=web,prod \
+    certificate=@web-cert.pem \
+    lease=3600
 ...
 ```
 

website/source/docs/auth/userpass.html.md

@@ -83,7 +83,9 @@ users that are allowed to authenticate. An example is shown below.
 Use `vault path-help` for more details.
 
 ```
-$ vault write auth/userpass/users/mitchellh password=foo policies=root
+$ vault write auth/userpass/users/mitchellh \
+    password=foo \
+    policies=root
 ...
 ```
 

website/source/docs/commands/read-write.html.md

@@ -22,7 +22,8 @@ to discover the paths.
 To write data to Vault, you use `vault write`. It is very easy to use:
 
 ```
-$ vault write secret/password value=itsasecret
+$ vault write secret/password \
+    value=itsasecret
 ...
 ```
 
@@ -30,7 +31,9 @@ The above writes a value to `secret/password`. As mentioned in the getting
 started guide, multiple values can also be written:
 
 ```
-$ vault write secret/password value=itsasecret username=something
+$ vault write secret/password \
+    value=itsasecret \
+    username=something
 ...
 ```
 

website/source/docs/http/index.html.md

@@ -63,7 +63,7 @@ This maps to `secret/foo` where `foo` is the key in the `secret/` backend/
 Here is an example of reading a secret using cURL:
 
 ```shell
-curl \
+$ curl \
     -H "X-Vault-Token: f3b09679-3001-009d-2b80-9c306ab81aa6" \
     -X GET \
     http://127.0.0.1:8200/v1/secret/foo
@@ -86,7 +86,7 @@ with a JSON body like:
 Here is an example of writing a secret using cURL:
 
 ```shell
-curl \
+$ curl \
     -H "X-Vault-Token: f3b09679-3001-009d-2b80-9c306ab81aa6" \
     -H "Content-Type: application/json" \
     -X POST \

website/source/docs/http/sys-health.html.md

@@ -33,7 +33,7 @@ description: |-
 	<dt>Returns</dt>
 	<dd>
 
-```
+    ```javascript
     {
       "initialized": true,
       "sealed": false,

website/source/docs/secrets/cassandra/index.html.md

@@ -38,7 +38,9 @@ writing one or more hosts, a username, and a password:
 
 ```text
 $ vault write cassandra/config/connection \
-    hosts=localhost username=cassandra password=cassandra
+    hosts=localhost \
+    username=cassandra \
+    password=cassandra
 ```
 
 In this case, we've configured Vault with the user "cassandra" and password "cassandra",

website/source/docs/secrets/consul/index.html.md

@@ -31,7 +31,9 @@ Next, we must configure Vault to know how to contact Consul.
 This is done by writing the access information:
 
 ```
-$ vault write consul/config/access address=127.0.0.1:8500 token=root
+$ vault write consul/config/access \
+    address=127.0.0.1:8500 \
+    token=root
 Success! Data written to: consul/config/access
 ```
 

website/source/docs/secrets/cubbyhole/index.html.md

@@ -34,7 +34,8 @@ As an example, we can write a new key "foo" to the `cubbyhole` backend, which
 is mounted at `cubbyhole/`:
 
 ```
-$ vault write cubbyhole/foo zip=zap
+$ vault write cubbyhole/foo \
+    zip=zap
 Success! Data written to: cubbyhole/foo
 ```
 

website/source/docs/secrets/generic/index.html.md

@@ -39,7 +39,9 @@ As an example, we can write a new key "foo" to the generic backend
 mounted at "secret/" by default:
 
 ```
-$ vault write secret/foo zip=zap ttl=1h
+$ vault write secret/foo \
+    zip=zap \
+    ttl=1h
 Success! Data written to: secret/foo
 ```
 

website/source/docs/secrets/mysql/index.html.md

@@ -40,7 +40,8 @@ Next, we must configure Vault to know how to connect to the MySQL
 instance. This is done by providing a DSN (Data Source Name):
 
 ```
-$ vault write mysql/config/connection value="root:root@tcp(192.168.33.10:3306)/"
+$ vault write mysql/config/connection \
+    value="root:root@tcp(192.168.33.10:3306)/"
 Success! Data written to: mysql/config/connection
 ```
 
@@ -53,7 +54,9 @@ Optionally, we can configure the lease settings for credentials generated
 by Vault. This is done by writing to the `config/lease` key:
 
 ```
-$ vault write mysql/config/lease lease=1h lease_max=24h
+$ vault write mysql/config/lease \
+    lease=1h \
+    lease_max=24h
 Success! Data written to: mysql/config/lease
 ```
 
@@ -67,7 +70,8 @@ to a policy used to generate those credentials. For example, lets create
 a "readonly" role:
 
 ```
-$ vault write mysql/roles/readonly sql="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON *.* TO '{{name}}'@'%';"
+$ vault write mysql/roles/readonly \
+    sql="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON *.* TO '{{name}}'@'%';"
 Success! Data written to: mysql/roles/readonly
 ```
 

website/source/docs/secrets/pki/index.html.md

@@ -74,7 +74,8 @@ Successfully mounted 'pki' at 'pki'!
 Next, Vault must be configured with a root certificate and associated private key. This is done by writing the contents of a file or *stdin*:
 
 ```text
-$ vault write pki/config/ca pem_bundle="@ca_bundle.pem"
+$ vault write pki/config/ca \
+    pem_bundle="@ca_bundle.pem"
 Success! Data written to: pki/config/ca
 ```
 
@@ -99,7 +100,8 @@ Success! Data written to: pki/roles/example-dot-com
 By writing to the `roles/example-dot-com` path we are defining the `example-dot-com` role. To generate a new set of credentials, we simply write to the `issue` endpoint with that role name: Vault is now configured to create and manage certificates!
 
 ```text
-$ vault write pki/issue/example-dot-com common_name=blah.example.com
+$ vault write pki/issue/example-dot-com \
+    common_name=blah.example.com
 Key            	Value
 lease_id       	pki/issue/example-dot-com/819393b5-e1a1-9efd-b72f-4dc3a1972e31
 lease_duration 	259200
@@ -218,14 +220,20 @@ If you get stuck at any time, simply run `vault path-help pki` or with a subpath
     command similar to the following:<br/>
 
     ```text
-    curl -X POST --data "@cabundle.json" http://127.0.0.1:8200/v1/pki/config/ca -H X-Vault-Token:06b9d...
+    $ curl \
+        -H "X-Vault-Token:06b9d..." \
+        -X POST \
+        --data "@cabundle.json" \
+        http://127.0.0.1:8200/v1/pki/config/ca
     ```
 
     Note that if you provide the data through the HTTP API it must be
     JSON-formatted, with newlines replaced with `\n`, like so:
 
-    ```text
-    { "pem_bundle": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END CERTIFICATE-----" }
+    ```javascript
+    {
+      "pem_bundle": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END CERTIFICATE-----"
+    }
     ```
   </dd>
 
@@ -434,6 +442,7 @@ If you get stuck at any time, simply run `vault path-help pki` or with a subpath
 
   <dt>Returns</dt>
   <dd>
+
     ```javascript
     {
       "data": {

website/source/docs/secrets/ssh/index.html.md

@@ -30,7 +30,7 @@ on every path, use `vault path-help` after mounting the backend.
 The `ssh` backend is not mounted by default and needs to be explicitly mounted.
 This is a common step for both OTP and Dynamic Key types.
 
-```shell
+```text
 $ vault mount ssh
 Successfully mounted 'ssh' at 'ssh'!
 ```
@@ -69,8 +69,11 @@ Create a role with the `key_type` parameter set to `otp`. All of the machines
 represented by the role's CIDR list should have helper properly installed and
 configured.
 
-```shell
-$ vault write ssh/roles/otp_key_role key_type=otp default_user=username cidr_list=x.x.x.x/y,m.m.m.m/n
+```text
+$ vault write ssh/roles/otp_key_role \
+    key_type=otp \
+    default_user=username \
+    cidr_list=x.x.x.x/y,m.m.m.m/n
 Success! Data written to: ssh/roles/otp_key_role
 ```
 
@@ -78,7 +81,7 @@ Success! Data written to: ssh/roles/otp_key_role
 
 Create an OTP credential for an IP that belongs to `otp_key_role`.
 
-```shell
+```text
 $ vault write ssh/creds/otp_key_role ip=x.x.x.x
 Key            	Value
 lease_id       	ssh/creds/otp_key_role/73bbf513-9606-4bec-816c-5a2f009765a5
@@ -93,7 +96,7 @@ key_type       	otp
 
 ### Establish an SSH session
 
-```shell
+```text
 $ ssh username@localhost
 Password: <Enter OTP>
 username@ip:~$
@@ -104,7 +107,7 @@ username@ip:~$
 A single CLI command can be used to create a new OTP and invoke SSH with the
 correct paramters to connect to the host.
 
-```shell
+```text
 $ vault ssh -role otp_key_role username@x.x.x.x
 OTP for the session is `b4d47e1b-4879-5f4e-ce5c-7988d7986f37`
 [Note: Install `sshpass` to automate typing in OTP]
@@ -113,7 +116,7 @@ Password: <Enter OTP>
 
 The OTP will be entered automatically using `sshpass` if it is installed.
 
-```shell
+```text
 $ vault ssh -role otp_key_role username@x.x.x.x
 username@ip:~$
 ```
@@ -183,8 +186,9 @@ First, however, the shared secret key must be specified.
 Register a key with a name; this key must have administrative capabilities
 on the remote hosts.
 
-```shell
-$ vault write ssh/keys/dev_key key=@dev_shared_key.pem
+```text
+$ vault write ssh/keys/dev_key \
+    key=@dev_shared_key.pem
 ```
 
 #### Create a Role
@@ -192,8 +196,13 @@ $ vault write ssh/keys/dev_key key=@dev_shared_key.pem
 Next, create a role. All of the machines contained within this CIDR block list
 should be accessible using the registered shared secret key.
 
-```shell
-$ vault write ssh/roles/dynamic_key_role key_type=dynamic key=dev_key admin_user=username default_user=username cidr_list=x.x.x.x/y
+```text
+$ vault write ssh/roles/dynamic_key_role \
+    key_type=dynamic \
+    key=dev_key \
+    admin_user=username \
+    default_user=username \
+    cidr_list=x.x.x.x/y
 Success! Data written to: ssh/roles/dynamic_key_role
 ```
 
@@ -212,7 +221,7 @@ To see the default, see [linux_install_script.go](https://github.com/hashicorp/v
 Create a dynamic key for an IP that is covered by `dynamic_key_role`'s CIDR
 list.
 
-```shell
+```text
 $ vault write ssh/creds/dynamic_key_role ip=x.x.x.x
 Key            	Value
 lease_id       	ssh/creds/dynamic_key_role/8c4d2042-23bc-d6a8-42c2-6ff01cb83cf8
@@ -256,7 +265,7 @@ username       	username
 Save the key to a file (e.g. `dyn_key.pem`) and then use it to establish an
 SSH session.
 
-```shell
+```text
 $ ssh -i dyn_key.pem username@ip
 username@ip:~$
 ```
@@ -266,7 +275,7 @@ username@ip:~$
 Creation of new key, saving to a file, and using it to establish an SSH session
 can all be done with a single Vault CLI command.
 
-```shell
+```text
 $ vault ssh -role dynamic_key_role username@ip
 username@ip:~$
 ```
@@ -476,6 +485,7 @@ username@ip:~$
   "port": 22
 }
 ```
+
   </dd>
 
   <dd>For an OTP role:

website/source/docs/secrets/transit/index.html.md

@@ -183,6 +183,7 @@ only encrypt or decrypt using the named keys they need access to.
   <dd>
 
     ```javascript
+    {
       "data": {
         "cipher_mode": "aes-gcm",
         "deletion_allowed": false,
@@ -190,10 +191,10 @@ only encrypt or decrypt using the named keys they need access to.
         "keys": {
           "1": 1442851412
         },
-    {
         "min_decryption_version": 0,
         "name": "foo"
       }
+    }
     ```
 
   </dd>