Standardize codeblock fences (bash)

Find and replace bash with shell

doc/administration/auth/ldap-ee.md

@@ -465,7 +465,7 @@ step of the sync.
 1. Start a Rails console:
-   ```bash
+   ```shell
    # For Omnibus installations
    sudo gitlab-rails console
@@ -540,7 +540,7 @@ statements.
 Indicates the point where syncing actually begins:
-```bash
+```shell
 Started syncing all providers for 'my_group' group
 ```
@@ -551,7 +551,7 @@ log entries like this - one for each LDAP group. If you don't see an LDAP user
 DN in this log entry, LDAP is not returning the user when we do the lookup.
 Verify the user is actually in the LDAP group.
-```bash
+```shell
 Members in 'ldap_group_1' LDAP group: ["uid=john0,ou=people,dc=example,dc=com",
 "uid=mary0,ou=people,dc=example,dc=com", "uid=john1,ou=people,dc=example,dc=com",
 "uid=mary1,ou=people,dc=example,dc=com", "uid=john2,ou=people,dc=example,dc=com",
@@ -571,7 +571,7 @@ NOTE: **Note:**
 10 is 'Guest', 20 is 'Reporter', 30 is 'Developer', 40 is 'Maintainer'
 and 50 is 'Owner'.
-```bash
+```shell
 Resolved 'my_group' group member access: {"uid=john0,ou=people,dc=example,dc=com"=>30,
 "uid=mary0,ou=people,dc=example,dc=com"=>30, "uid=john1,ou=people,dc=example,dc=com"=>30,
 "uid=mary1,ou=people,dc=example,dc=com"=>30, "uid=john2,ou=people,dc=example,dc=com"=>30,
@@ -588,7 +588,7 @@ If you think a particular user should already exist in GitLab, but you're seeing
 this entry, it could be due to a mismatched DN stored in GitLab. See
 [User DN has changed](#User-DN-has-changed) to update the user's LDAP identity.
-```bash
+```shell
 User with DN `uid=john0,ou=people,dc=example,dc=com` should have access
 to 'my_group' group but there is no user in GitLab with that
 identity. Membership will be updated once the user signs in for
@@ -597,6 +597,6 @@ the first time.
 Finally, the following entry says syncing has finished for this group:
-```bash
+```shell
 Finished syncing all providers for 'my_group' group
 ```

doc/administration/auth/ldap.md

@@ -583,7 +583,7 @@ ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt  -b "$ba
 - Run the following check command to make sure that the LDAP settings are
   correct and GitLab can see your users:
-  ```bash
+  ```shell
   # For Omnibus installations
   sudo gitlab-rake gitlab:ldap:check

doc/administration/file_hooks.md

@@ -94,7 +94,7 @@ The rake task will use a sample data and execute each of file hook. The output
 should be enough to determine if the system sees your file hook and if it was
 executed without errors.
-```bash
+```shell
 # Omnibus installations
 sudo gitlab-rake file_hooks:validate

doc/administration/geo/disaster_recovery/index.md

@@ -135,7 +135,7 @@ do this manually.
 1. SSH in to the database node in the **secondary** and trigger PostgreSQL to
    promote to read-write:
-   ```bash
+   ```shell
    sudo gitlab-pg-ctl promote
    ```
@@ -157,7 +157,7 @@ do this manually.
 1. Promote the **secondary** to **primary**. SSH into a single application
    server and execute:
-   ```bash
+   ```shell
    sudo gitlab-rake geo:set_secondary_as_primary
    ```

doc/administration/geo/replication/external_database.md

@@ -13,13 +13,13 @@ developed and tested. We aim to be compatible with most external
 1. SSH into a GitLab **primary** application server and login as root:
-   ```bash
+   ```shell
    sudo -i
    ```
 1. Execute the command below to define the node as **primary** node:
-   ```bash
+   ```shell
    gitlab-ctl set-geo-primary-node
    ```
@@ -100,7 +100,7 @@ To configure the connection to the external read-replica database and enable Log
 1. SSH into a GitLab **secondary** application server and login as root:
-   ```bash
+   ```shell
    sudo -i
    ```
@@ -147,7 +147,7 @@ the tracking database on port 5432.
 1. SSH into a GitLab **secondary** server and login as root:
-   ```bash
+   ```shell
    sudo -i
    ```
@@ -168,7 +168,7 @@ the tracking database on port 5432.
 1. Run the tracking database migrations:
-   ```bash
+   ```shell
    gitlab-rake geo:db:create
    gitlab-rake geo:db:migrate
    ```
@@ -179,7 +179,7 @@ the tracking database on port 5432.
    Save the script below in a file, ex. `/tmp/geo_fdw.sh` and modify the connection
    params to match your environment. Execute it to set up the FDW connection.
-   ```bash
+   ```shell
    #!/bin/bash
    # Secondary Database connection params:
@@ -213,6 +213,6 @@ the tracking database on port 5432.
 1. Save the file and [restart GitLab](../../restart_gitlab.md#omnibus-gitlab-restart)
 1. Populate the FDW tables:
-   ```bash
+   ```shell
    gitlab-rake geo:db:refresh_foreign_tables
    ```

doc/administration/geo/replication/remove_geo_node.md

@@ -10,13 +10,13 @@ Once removed from the Geo admin page, you must stop and uninstall the **secondar
 1. On the **secondary** node, stop GitLab:
-   ```bash
+   ```shell
    sudo gitlab-ctl stop
    ```
 1. On the **secondary** node, uninstall GitLab:
-   ```bash
+   ```shell
    # Stop gitlab and remove its supervision process
    sudo gitlab-ctl uninstall
@@ -31,7 +31,7 @@ Once GitLab has been uninstalled from the **secondary** node, the replication sl
 1. On the **primary** node, start a PostgreSQL console session:
-   ```bash
+   ```shell
    sudo gitlab-psql
    ```

doc/administration/geo/replication/using_a_geo_server.md

@@ -8,7 +8,7 @@ Pushing directly to a **secondary** node (for both HTTP, SSH including Git LFS)
 Example of the output you will see when pushing to a **secondary** node:
-```bash
+```shell
 $ git push
 remote:
 remote: You're pushing to a Geo secondary. We'll help you by proxying this

doc/administration/geo/replication/version_specific_updates.md

@@ -357,7 +357,7 @@ is prepended with the relevant node for better clarity:
    1. **(secondary)** Save the snippet below in a file, let's say `/tmp/replica.sh`. Modify the
       embedded paths if necessary:
-      ```bash
+      ```shell
       #!/bin/bash
       PORT="5432"

doc/administration/git_annex.md

@@ -96,7 +96,7 @@ one is located in `config.yml` of GitLab Shell.
 Here is an example workflow of uploading a very large file and then checking it
 into your Git repository:
-```bash
+```shell
 git clone git@example.com:group/project.git
 git annex init 'My Laptop'       # initialize the annex project and give an optional description
@@ -165,7 +165,7 @@ repository.
 Downloading a single large file is also very simple:
-```bash
+```shell
 git clone git@gitlab.example.com:group/project.git
 git annex sync             # sync Git branches but not the large file
@@ -174,7 +174,7 @@ git annex get debian.iso   # download the large file
 To download all files:
-```bash
+```shell
 git clone git@gitlab.example.com:group/project.git
 git annex sync --content  # sync Git branches and download all the large files

doc/administration/gitaly/index.md

@@ -1009,7 +1009,7 @@ If you are having trouble connecting to a Gitaly node with command line (CLI) to
 Verify that you can reach Gitaly via TCP:
-```bash
+```shell
 sudo gitlab-rake gitlab:tcp_check[GITALY_SERVER_IP,GITALY_LISTEN_PORT]
 ```
@@ -1019,7 +1019,7 @@ If you use proxy servers in your command line environment, such as Bash, these c
 If you use Bash or a compatible command line environment, run the following commands to determine whether you have proxy servers configured:
-```bash
+```shell
 echo $http_proxy
 echo $https_proxy
 ```
@@ -1028,7 +1028,7 @@ If either of these variables have a value, your Gitaly CLI connections may be ge
 To remove the proxy setting, run the following commands (depending on which variables had values):
-```bash
+```shell
 unset http_proxy
 unset https_proxy
 ```

doc/administration/high_availability/nfs.md

@@ -186,7 +186,7 @@ single NFS mount point as you normally would in `/etc/fstab`. Let's assume your
 NFS mount point is `/gitlab-nfs`. Then, add the following bind mounts in
 `/etc/fstab`:
-```bash
+```shell
 /gitlab-nfs/gitlab-data/git-data /var/opt/gitlab/git-data none bind 0 0
 /gitlab-nfs/gitlab-data/.ssh /var/opt/gitlab/.ssh none bind 0 0
 /gitlab-nfs/gitlab-data/uploads /var/opt/gitlab/gitlab-rails/uploads none bind 0 0

doc/administration/high_availability/redis.md

@@ -978,7 +978,7 @@ To make sure your configuration is correct:
 1. To simulate a failover on master Redis, SSH into the Redis server and run:
-   ```bash
+   ```shell
    # port must match your master redis port, and the sleep time must be a few seconds bigger than defined one
     redis-cli -h localhost -p 6379 DEBUG sleep 20
    ```

doc/administration/invalidate_markdown_cache.md

@@ -11,6 +11,6 @@ increasing the `local_markdown_version` setting in application settings.  This c
 be done by [changing the application settings through
 the API](../api/settings.md#change-application-settings):
-```bash
+```shell
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/settings?local_markdown_version=<increased_number>
 ```

doc/administration/job_artifacts.md

@@ -156,7 +156,7 @@ _The artifacts are stored by default in
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
 1. Migrate any existing local artifacts to the object storage:
-   ```bash
+   ```shell
    gitlab-rake gitlab:artifacts:migrate
    ```
@@ -184,7 +184,7 @@ _The artifacts are stored by default in
 1. Save the file and [restart GitLab][] for the changes to take effect.
 1. Migrate any existing local artifacts to the object storage:
-   ```bash
+   ```shell
    sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production
    ```

doc/administration/lfs/lfs_administration.md

@@ -178,7 +178,7 @@ On Omnibus installations, the settings are prefixed by `lfs_object_store_`:
 1. Save the file and [reconfigure GitLab]s for the changes to take effect.
 1. Migrate any existing local LFS objects to the object storage:
-   ```bash
+   ```shell
    gitlab-rake gitlab:lfs:migrate
    ```
@@ -214,7 +214,7 @@ For source installations the settings are nested under `lfs:` and then
 1. Save the file and [restart GitLab][] for the changes to take effect.
 1. Migrate any existing local LFS objects to the object storage:
-   ```bash
+   ```shell
    sudo -u git -H bundle exec rake gitlab:lfs:migrate RAILS_ENV=production
    ```

doc/administration/lfs/manage_large_binaries_with_git_lfs.md

@@ -50,7 +50,7 @@ Lets take a look at the workflow when you need to check large files into your Gi
 repository with Git LFS. For example, if you want to upload a very large file and
 check it into your Git repository:
-```bash
+```shell
 git clone git@gitlab.example.com:group/project.git
 git lfs install                       # initialize the Git LFS project
 git lfs track "*.iso"                 # select the file extensions that you want to treat as large files
@@ -59,7 +59,7 @@ git lfs track "*.iso"                 # select the file extensions that you want
 Once a certain file extension is marked for tracking as a LFS object you can use
 Git as usual without having to redo the command to track a file with the same extension:
-```bash
+```shell
 cp ~/tmp/debian.iso ./                # copy a large file into the current directory
 git add .                             # add the large file to the project
 git commit -am "Added Debian iso"     # commit the file meta data
@@ -69,7 +69,7 @@ git push origin master                # sync the git repo and large file to the
 **Make sure** that `.gitattributes` is tracked by Git. Otherwise Git
 LFS will not be working properly for people cloning the project:
-```bash
+```shell
 git add .gitattributes
 ```
@@ -78,14 +78,14 @@ LFS-tracked files and clones them via HTTP. If you performed the `git clone`
 command with a SSH URL, you have to enter your GitLab credentials for HTTP
 authentication.
-```bash
+```shell
 git clone git@gitlab.example.com:group/project.git
 ```
 If you already cloned the repository and you want to get the latest LFS object
 that are on the remote repository, eg. for a branch from origin:
-```bash
+```shell
 git lfs fetch origin master
 ```
@@ -101,14 +101,14 @@ The first thing to do before using File Locking is to tell Git LFS which
 kind of files are lockable. The following command will store PNG files
 in LFS and flag them as lockable:
-```bash
+```shell
 git lfs track "*.png" --lockable
 ```
 After executing the above command a file named `.gitattributes` will be
 created or updated with the following content:
-```bash
+```shell
 *.png filter=lfs diff=lfs merge=lfs -text lockable
 ```
@@ -116,7 +116,7 @@ You can also register a file type as lockable without using LFS
 (In order to be able to lock/unlock a file you need a remote server that implements the  LFS File Locking API),
 in order to do that you can edit the `.gitattributes` file manually:
-```bash
+```shell
 *.pdf lockable
 ```
@@ -128,14 +128,14 @@ need to lock the file before editing it.
 Once you're ready to edit your file you need to lock it first:
-```bash
+```shell
 git lfs lock images/banner.png
 Locked images/banner.png
 ```
 This will register the file as locked in your name on the server:
-```bash
+```shell
 git lfs locks
 images/banner.png  joe   ID:123
 ```
@@ -143,13 +143,13 @@ images/banner.png  joe   ID:123
 Once you have pushed your changes, you can unlock the file so others can
 also edit it:
-```bash
+```shell
 git lfs unlock images/banner.png
 ```
 You can also unlock by id:
-```bash
+```shell
 git lfs unlock --id=123
 ```
@@ -157,7 +157,7 @@ If for some reason you need to unlock a file that was not locked by you,
 you can use the `--force` flag as long as you have a `maintainer` access on
 the project:
-```bash
+```shell
 git lfs unlock --id=123 --force
 ```
@@ -183,7 +183,7 @@ available to the project anymore. Probably the object was removed from the serve
 Git LFS will log the failures into a log file.
 To view this log file, while in project directory:
-```bash
+```shell
 git lfs logs last
 ```
@@ -215,7 +215,7 @@ This behaviour is caused by Git LFS using HTTPS connections by default when a
 To prevent this from happening, set the lfs url in project Git config:
-```bash
+```shell
 git config --add lfs.url "http://gitlab.example.com/group/project.git/info/lfs"
 ```
@@ -235,7 +235,7 @@ you use. This is described in [Git credentials man pages](https://git-scm.com/do
 For example, you can tell Git to remember the password for a period of time in
 which you expect to push the objects:
-```bash
+```shell
 git config --global credential.helper 'cache --timeout=3600'
 ```

doc/administration/lfs/migrate_from_git_annex_to_git_lfs.md

@@ -48,7 +48,7 @@ Fire up a terminal, navigate to your Git repository and:
 1. Disable `git-annex`:
-   ```bash
+   ```shell
    git annex sync --content
    git annex direct
    git annex uninit
@@ -85,7 +85,7 @@ if the server also has Git Annex 6 installed. Read more in the
 1. Backup your repository
-   ```bash
+   ```shell
    cd repository
    git annex sync --content
    cd ..
@@ -97,14 +97,14 @@ if the server also has Git Annex 6 installed. Read more in the
 1. Use `annex direct`:
-   ```bash
+   ```shell
    cd repository
    git annex direct
    ```
    The output should be similar to this:
-   ```bash
+   ```shell
    commit
    On branch master
    Your branch is up-to-date with 'origin/master'.
@@ -116,13 +116,13 @@ if the server also has Git Annex 6 installed. Read more in the
 1. Disable Git Annex with [`annex uninit`][uninit]:
-   ```bash
+   ```shell
    git annex uninit
    ```
    The output should be similar to this:
-   ```bash
+   ```shell
    unannex debian.iso ok
    Deleted branch git-annex (was 2534d2c).
    ```
@@ -131,13 +131,13 @@ if the server also has Git Annex 6 installed. Read more in the
 1. Switch back to `indirect` mode:
-   ```bash
+   ```shell
    git annex indirect
    ```
    The output should be similar to this:
-   ```bash
+   ```shell
    (merging origin/git-annex into git-annex...)
    (recording state in git...)
    commit  (recording state in git...)
@@ -165,7 +165,7 @@ GitLab.com), therefore, you don't need to do anything server-side.
 1. First, make sure you have `git-lfs` installed locally:
-   ```bash
+   ```shell
    git lfs help
    ```
@@ -174,7 +174,7 @@ GitLab.com), therefore, you don't need to do anything server-side.
 1. Inside the repo, run the following command to initiate LFS:
-   ```bash
+   ```shell
    git lfs install
    ```
@@ -182,7 +182,7 @@ GitLab.com), therefore, you don't need to do anything server-side.
    can track specific files, all files containing the same extension, or an
    entire directory:
-   ```bash
+   ```shell
    git lfs track images/01.png   # per file
    git lfs track **/*.png        # per extension
    git lfs track images/         # per directory
@@ -194,7 +194,7 @@ GitLab.com), therefore, you don't need to do anything server-side.
 1. Add the files, commit and push them to GitLab:
-   ```bash
+   ```shell
    git add .
    git commit -m "commit message"
    git push
@@ -217,7 +217,7 @@ branches created by Git Annex: `git-annex`, and all under `synced/`.
 You can also do this on the command line with:
-```bash
+```shell
 git branch -d synced/master
 git branch -d synced/git-annex
 git push origin :synced/master
@@ -229,7 +229,7 @@ git remote prune origin
 If there are still some Annex objects inside your repository (`.git/annex/`)
 or references inside `.git/config`, run `annex uninit` again:
-```bash
+```shell
 git annex uninit
 ```

doc/administration/monitoring/performance/gitlab_configuration.md

@@ -17,7 +17,7 @@ changes.
 Finally, a restart of all GitLab processes is required for the changes to take
 effect:
-```bash
+```shell
 # For Omnibus installations
 sudo gitlab-ctl restart

doc/administration/monitoring/performance/influxdb_configuration.md

@@ -110,14 +110,14 @@ buffer size is set to the same value, the default value is almost never enough.
 To set the OS buffer size to 200 MB, on Linux you can run the following command:
-```bash
+```shell
 sysctl -w net.core.rmem_max=209715200
 ```
 To make this permanent, add the following to `/etc/sysctl.conf` and restart the
 server:
-```bash
+```shell
 net.core.rmem_max=209715200
 ```
@@ -154,7 +154,7 @@ and password (`-password <password>`)  you set earlier to the commands below._
 Run the following command to create a database named `gitlab`:
-```bash
+```shell
 influx -execute 'CREATE DATABASE gitlab'
 ```
@@ -162,7 +162,7 @@ The name **must** be `gitlab`, do not use any other name.
 Next, make sure that the database was successfully created:
-```bash
+```shell
 influx -execute 'SHOW DATABASES'
 ```

doc/administration/operations/extra_sidekiq_processes.md

@@ -207,7 +207,7 @@ For debugging purposes, you can start extra Sidekiq processes by using the comma
 `/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster`. This command
 takes arguments using the following syntax:
-```bash
+```shell
 /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster [QUEUE,QUEUE,...] [QUEUE, ...]
 ```
@@ -225,14 +225,14 @@ For example, say you want to start 2 extra processes: one to process the
 `process_commit` queue, and one to process the `post_receive` queue. This can be
 done as follows:
-```bash
+```shell
 /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit post_receive
 ```
 If you instead want to start one process processing both queues, you'd use the
 following syntax:
-```bash
+```shell
 /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit,post_receive
 ```
@@ -240,7 +240,7 @@ If you want to have one Sidekiq process dealing with the `process_commit` and
 `post_receive` queues, and one process to process the `gitlab_shell` queue,
 you'd use the following:
-```bash
+```shell
 /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit,post_receive gitlab_shell
 ```
@@ -272,7 +272,7 @@ The `sidekiq-cluster` command can store its PID in a file. By default no PID
 file is written, but this can be changed by passing the `--pidfile` option to
 `sidekiq-cluster`. For example:
-```bash
+```shell
 /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster --pidfile /var/run/gitlab/sidekiq_cluster.pid process_commit
 ```