contributing: Validate Markdown files

* linter: turn Markdown validation on
* Markdown files cleanup

.github/workflows/README.md

@@ -4,7 +4,7 @@
 
 Run locally using Docker:
 
-```
+```bash
 docker run --rm -e RUN_LOCAL=true -e VALIDATE_PERL=true -v $PWD:/tmp/lint github/super-linter
 ```
 

.github/workflows/super-linter.yml

@@ -31,7 +31,7 @@ jobs:
           VALIDATE_JAVASCRIPT_ES: true
           VALIDATE_JAVASCRIPT_STANDARD: false
           VALIDATE_JSON: true
-          VALIDATE_MD: false
+          VALIDATE_MD: true
           VALIDATE_PERL: true
           VALIDATE_POWERSHELL: true
           VALIDATE_XML: true

CONTRIBUTING.md

@@ -23,36 +23,34 @@ GRASS GIS developer mailing list.
   of the GitHub interface).
 * Clone your fork (use HTTPS or SSH URL, here we will use HTTPS):
 
-```
-git clone https://github.com/your_GitHub_account/grass.git
+```bash
+git clone git@github.com:your_GH_account/grass.git
 ```
 
 * Enter the directory
 
-```
+```bash
 cd grass/
 ```
 
 * Add main GRASS GIS repository as "upstream" (use HTTPS URL):
 
-```
+```bash
 git remote add upstream https://github.com/OSGeo/grass
 ```
 
 * Your remotes now should be "origin" which is your fork and "upstream" which
   is this main GRASS GIS repository. You can confirm that using:
 
-```
+```bash
 git remote -v
 ```
 
 * You should see something like:
 
-```
-origin	https://github.com/your_GH_account/grass.git (fetch)
-origin	https://github.com/your_GH_account/grass.git (push)
-upstream	https://github.com/OSGeo/grass.git (fetch)
-upstream	https://github.com/OSGeo/grass.git (push)
+```bash
+origin  [email protected]:your_GH_account/grass.git (fetch)
+origin  [email protected]:your_GH_account/grass.git (push)
 ```
 
 For the following workflow, it is important that
@@ -64,20 +62,20 @@ and "origin" to your fork
 
 * Make sure your are using the _main_ branch to create the new branch:
 
-```
-git switch main
+```bash
+git checkout main
 ```
 
 * Download updates from all branches from the _upstream_ remote:
 
-```
+```bash
 git fetch upstream
 ```
 
 * Update your local _main_ branch to match the _main_ branch
   in the _upstream_ repository:
 
-```
+```bash
 git rebase upstream/main
 ```
 
@@ -90,19 +88,19 @@ rebase or merge happens).
 If `rebase` fails with "error: cannot rebase: You have unstaged changes...",
 then move your uncommitted local changes to "stash" using:
 
-```
+```bash
 git stash
 ```
 
 * Now you can rebase:
 
-```
+```bash
 git rebase upstream/main
 ```
 
 * Get the changes back from stash:
 
-```
+```bash
 git stash pop
 ```
 
@@ -113,7 +111,7 @@ based on it.
 
 * Create a new feature branch and switch to it:
 
-```
+```bash
 git checkout -b new-feature
 ```
 
@@ -142,29 +140,29 @@ request comment.
 
 Note that there are some steps you can do locally to improve your code.
 For Python, run `black .` to apply standardized formatting. You can
-also run linter tools such as Pylint which will suggest different improvements 
+also run linter tools such as Pylint which will suggest different improvements
 to your code.
 
 ### Committing
 
 * Add files to the commit (changed ones or new ones):
 
-```
+```bash
 git add file1
 git add file2
 ```
 
 * Commit the change (first word is the module name):
 
-```
+```bash
 git commit -m "module: added a new feature"
 ```
 
 ### Pushing changes to GitHub
 
 * Push your local feature branch to your fork:
 
-```
+```bash
 git push origin new-feature
 ```
 

INSTALL.md

@@ -65,7 +65,7 @@ For Solaris, see hints below.
 
 The command,
 
-```
+```bash
 ./configure --help
 ```
 
@@ -77,13 +77,13 @@ distributions, FreeBSD, AIX, etc) are available at:
 
 First step of the compilation (-g for debugging, or -O2 for optimization):
 
-```
+```bash
 CFLAGS="-g -Wall" ./configure
 ```
 
 Explanation of make targets:
 
-```
+```text
 make install       - installs the binary
 
 make bindist       - make a binary package with install script
@@ -104,7 +104,7 @@ make pdfdocs       - generate programmer's documentation as PDF files
 
 Next step is the compilation itself:
 
-```
+```bash
 make
 ```
 
@@ -115,13 +115,13 @@ install program (AC_PROG_INSTALL ignores versions which are known to
 have problems), you need to ensure that $srcdir is an absolute path,
 by using e.g.:
 
-```
+```bash
 `pwd`/configure ...
 ```
 
 or:
 
-```
+```bash
 ./configure --srcdir=`pwd` ...
 ```
 
@@ -132,7 +132,7 @@ Note when using a compiler different from "gcc":
 By setting environment variables, the compiler
 names can be defined (C and C++):
 
-```
+```bash
 CC=cc CPP=cpp ./configure ...
 ```
 
@@ -141,7 +141,7 @@ CC=cc CPP=cpp ./configure ...
 To successfully compile GRASS on 64bit platforms, the required
 FFTW2 library has to be compiled with -fPIC flag:
 
-```
+```bash
 #this applies to FFTW3, not to GRASS GIS:
 cd fftw-3.3.4/
 CFLAGS="-fPIC" ./configure
@@ -152,7 +152,7 @@ make install
 To fully enable 64bit library usage for GRASS on 64bit platforms,
 the following additional parameters are recommended/required:
 
-```
+```bash
 ./configure \
    --enable-64bit \
    --with-libs=/usr/lib64 \
@@ -165,25 +165,25 @@ See also CODE OPTIMIZATION below.
 
 After compilation, the resulting code is stored in the directory
 
-```
+```bash
 ./dist.$ARCH
 ```
 
 and the scripts (grass, ...) in
 
-```
+```bash
 ./bin.$ARCH
 ```
 
 To run GRASS, simply start
 
-```
+```bash
 ./bin.$ARCH/grass
 ```
 
 or run
 
-```
+```bash
 make install
 grass
 ```
@@ -212,7 +212,7 @@ GitHub, you have to perform a few steps. In general:
 
 In detail:
 
-```
+```bash
 cd /where/your/grass-source-code/lives/
 git fetch --all
 git merge upstream/main
@@ -229,27 +229,27 @@ To compile (self-made) GRASS modules or to compile modified modules
 at least the GRASS libraries have to be compiled locally. This is
 done by launching:
 
-```
+```bash
 make libs
 ```
 
 Then change into the module's directory and launch the "make"
 command. The installation can be either done with "make install" from
 the main source code directory or locally with
 
-```
+```bash
 "INST_NOW=y make"
 ```
 
 You may want to define an alias for this:
 
-```
+```bash
 alias gmake='INST_NOW=y make'
 ```
 
 Then simply compile/install the current module with
 
-```
+```bash
 gmake
 ```
 
@@ -262,13 +262,13 @@ path(s) in the Makefile to absolute path(s).
 If you would like to set compiler optimisations, for a possibly faster
 binary, type (don't enter a ";" anywhere):
 
-```
+```bash
 CFLAGS=-O ./configure
 ```
 
 or,
 
-```
+```bash
 setenv CFLAGS -O
 ./configure
 ```
@@ -278,7 +278,7 @@ supports this (note: O is the letter, not zero). Using the "gcc" compiler,
 you can also specify processor specific flags (examples, please suggest
 better settings to us):
 
-```
+```bash
 CFLAGS="-mcpu=athlon -O2" # AMD Athlon processor with code optimisations
 CFLAGS="-mcpu=pentium" # Intel Pentium processor
 CFLAGS="-mcpu=pentium4" # Intel Pentium4 processor
@@ -292,7 +292,7 @@ by the local machine at GCC runtime including -mtune.
 
 To find out optional CFLAGS for your platform, enter:
 
-```
+```bash
 gcc -dumpspecs
 ```
 
@@ -301,7 +301,7 @@ See also: <https://gcc.gnu.org/>
 A real fast GRASS version (and small binaries) will be created with
 LDFLAGS set to "stripping" (but this disables debugging):
 
-```
+```bash
 CFLAGS="-O2 -mcpu=<cpu_see_above> -Wall" LDFLAGS="-s" ./configure
 ```
 
@@ -317,7 +317,7 @@ the source code.
 
 The `-g` and `-Wall` compiler flags are often useful for assisting debugging:
 
-```
+```bash
 CFLAGS="-g -Wall" ./configure
 ```
 
@@ -329,7 +329,7 @@ See also the file ./doc/debugging.txt and the Wiki page
 GRASS GIS includes improved support for reading and writing large files
 (> 2GB) if it is possible in your operating system. If you compile with
 
-```
+```bash
 configure [...] --enable-largefile
 ```