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: #33510
Reviewed-By: Michaël Zasso <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>

Author: Derek Lewis

doc/api/deprecations.md

@@ -1595,7 +1595,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');

doc/api/esm.md

@@ -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

doc/api/modules.md

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

doc/api/policy.md

@@ -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
 ```
 

doc/api/tls.md

@@ -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"

doc/api/tty.md

@@ -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

doc/guides/collaborator-guide.md

@@ -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

doc/guides/maintaining-openssl.md

@@ -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

doc/guides/onboarding-extras.md

@@ -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

doc/guides/releases.md

@@ -576,22 +576,22 @@ 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':
 [email protected]'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
 ```