doc: normalize Bash code block info strings

Prior to this commit, Bash fenced code blocks in Markdown files had
inconsistent info strings. This has been corrected to standardize on
the less-obscure variant.

PR-URL: https://github.com/nodejs/node/pull/33510
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
pull/33486/merge
Derek Lewis 2020-05-22 02:33:40 -04:00 committed by Ruben Bridgewater
parent e278e3176a
commit 549812a9a0
11 changed files with 25 additions and 25 deletions

View File

@ -1601,7 +1601,7 @@ querystring.parse(str, '\n', '=');
This function is not completely equivalent to `querystring.parse()`. One
difference is that `querystring.parse()` does url decoding:
```sh
```console
> querystring.parse('%E5%A5%BD=1', '\n', '=');
{ '好': '1' }
> tls.parseCertString('%E5%A5%BD=1');

View File

@ -94,7 +94,7 @@ until the root of the volume is reached.
}
```
```sh
```bash
# In same folder as above package.json
node my-app.js # Runs as ES module
```
@ -184,7 +184,7 @@ Strings passed in as an argument to `--eval` (or `-e`), or piped to `node` via
`STDIN`, will be treated as ES modules when the `--input-type=module` flag is
set.
```sh
```bash
node --input-type=module --eval "import { sep } from 'path'; console.log(sep);"
echo "import { sep } from 'path'; console.log(sep);" | node --input-type=module

View File

@ -680,7 +680,7 @@ In `entry.js` script:
console.log(require.main);
```
```sh
```bash
node entry.js
```

View File

@ -31,7 +31,7 @@ when loading modules.
Once this has been set, all modules must conform to a policy manifest file
passed to the flag:
```sh
```bash
node --experimental-policy=policy.json app.js
```
@ -43,7 +43,7 @@ the policy file itself may be provided via `--policy-integrity`.
This allows running `node` and asserting the policy file contents
even if the file is changed on disk.
```sh
```bash
node --experimental-policy=policy.json --policy-integrity="sha384-SggXRQHwCG8g+DktYYzxkXRIkTiEYWBHqev0xnpCxYlqMBufKZHAHQM3/boDaI/0" app.js
```

View File

@ -21,7 +21,7 @@ Private keys can be generated in multiple ways. The example below illustrates
use of the OpenSSL command-line interface to generate a 2048-bit RSA private
key:
```sh
```bash
openssl genrsa -out ryans-key.pem 2048
```
@ -35,7 +35,7 @@ step to obtaining a certificate is to create a *Certificate Signing Request*
The OpenSSL command-line interface can be used to generate a CSR for a private
key:
```sh
```bash
openssl req -new -sha256 -key ryans-key.pem -out ryans-csr.pem
```
@ -45,14 +45,14 @@ Authority for signing or used to generate a self-signed certificate.
Creating a self-signed certificate using the OpenSSL command-line interface
is illustrated in the example below:
```sh
```bash
openssl x509 -req -in ryans-csr.pem -signkey ryans-key.pem -out ryans-cert.pem
```
Once the certificate is generated, it can be used to generate a `.pfx` or
`.p12` file:
```sh
```bash
openssl pkcs12 -export -in ryans-cert.pem -inkey ryans-key.pem \
-certfile ca-cert.pem -out ryans.pfx
```
@ -95,7 +95,7 @@ to generate Diffie-Hellman parameters and specify them with the `dhparam`
option to [`tls.createSecureContext()`][]. The following illustrates the use of
the OpenSSL command-line interface to generate such parameters:
```sh
```bash
openssl dhparam -outform PEM -out dhparam.pem 2048
```
@ -250,7 +250,7 @@ failures, it is easy to not notice unnecessarily poor TLS performance. The
OpenSSL CLI can be used to verify that servers are resuming sessions. Use the
`-reconnect` option to `openssl s_client`, for example:
```sh
```console
$ openssl s_client -connect localhost:443 -reconnect
```
@ -304,7 +304,7 @@ line switch (directly, or via the [`NODE_OPTIONS`][] environment variable). For
instance, the following makes `ECDHE-RSA-AES128-GCM-SHA256:!RC4` the default TLS
cipher suite:
```sh
```bash
node --tls-cipher-list="ECDHE-RSA-AES128-GCM-SHA256:!RC4" server.js
export NODE_OPTIONS=--tls-cipher-list="ECDHE-RSA-AES128-GCM-SHA256:!RC4"

View File

@ -19,7 +19,7 @@ default be instances of `tty.WriteStream`. The preferred method of determining
whether Node.js is being run within a TTY context is to check that the value of
the `process.stdout.isTTY` property is `true`:
```sh
```console
$ node -p -e "Boolean(process.stdout.isTTY)"
true
$ node -p -e "Boolean(process.stdout.isTTY)" | cat

View File

@ -638,7 +638,7 @@ That means a commit has landed since your last rebase against `upstream/master`.
To fix this, pull with rebase from upstream, run the tests again, and (if the
tests pass) push again:
```sh
```bash
git pull upstream master --rebase
make -j4 test
git push upstream master

View File

@ -10,7 +10,7 @@ This document describes how to update `deps/openssl/`.
## 0. Check Requirements
```sh
```console
% perl -v
This is perl 5, version 22, subversion 1 (v5.22.1) built for
@ -30,7 +30,7 @@ NASM version 2.11.08
Get a new source from <https://www.openssl.org/source/> and extract
all files into `deps/openssl/openssl`. Then add all files and commit
them.
```sh
```console
% cd deps/openssl/
% rm -rf openssl
% tar zxf ~/tmp/openssl-1.1.0h.tar.gz
@ -57,7 +57,7 @@ This updates all sources in deps/openssl/openssl by:
Use `make` to regenerate all platform dependent files in
`deps/openssl/config/archs/`:
```sh
```console
% make -C deps/openssl/config
```
@ -66,7 +66,7 @@ Use `make` to regenerate all platform dependent files in
Check diffs to ensure updates are right. Even if there are no updates in openssl
sources, `buildinf.h` files will be updated because they have timestamp
data in them.
```sh
```console
% git diff -- deps/openssl
```
@ -81,7 +81,7 @@ please ask @shigeki for details.
Update all architecture dependent files. Do not forget to git add or remove
files if they are changed before committing:
```sh
```console
% git add deps/openssl/config/archs
% git add deps/openssl/openssl/include/crypto/bn_conf.h
% git add deps/openssl/openssl/include/crypto/dso_conf.h

View File

@ -37,7 +37,7 @@ request.
* A breaking change helper
([full source](https://gist.github.com/chrisdickinson/ba532fa0e4e243fb7b44)):
```sh
```bash
SHOW=$(git show-ref -d $(git describe --abbrev=0) | tail -n1 | awk '{print $1}')
git checkout $(git show -s --pretty='%T' $SHOW) -- test
make -j4 test

View File

@ -576,7 +576,7 @@ same GPG key!**
Use `tools/release.sh` to promote and sign the build. Before doing this, you'll
need to ensure you've loaded the correct ssh key, or you'll see the following:
```sh
```console
# Checking for releases ...
Enter passphrase for key '/Users/<user>/.ssh/id_rsa':
dist@direct.nodejs.org's password:
@ -584,14 +584,14 @@ dist@direct.nodejs.org's password:
The key can be loaded either with `ssh-add`:
```sh
```console
# Substitute node_id_rsa with whatever you've named the key
$ ssh-add ~/.ssh/node_id_rsa
```
or at runtime with:
```sh
```console
# Substitute node_id_rsa with whatever you've named the key
$ ./tools/release.sh -i ~/.ssh/node_id_rsa
```

View File

@ -6,7 +6,7 @@ can be created by using `asn1.js` and `asn1.js-rfc5280`,
## How to create a test cert.
```sh
```console
$ openssl genrsa -out 0-dns-key.pem 2048
Generating RSA private key, 2048 bit long modulus
...................+++