Harmonize Bash command syntax for easier line selection and copy-pasting

- Remove prompt or `$` sign which makes triple-click based selection
  more difficult and time-consuming.
- Use `platform` instead of `p` alias in all SCons examples.

contributing/development/compiling/compiling_for_ios.rst

@@ -53,13 +53,13 @@ Open a Terminal, go to the root dir of the engine source code and type:
 
 ::
 
-    $ scons p=ios target=template_debug
+    scons platform=ios target=template_debug
 
 for a debug build, or:
 
 ::
 
-    $ scons p=ios target=template_release
+    scons platform=ios target=template_release
 
 for a release build (check ``platform/ios/detect.py`` for the compiler
 flags used for each configuration).
@@ -68,8 +68,8 @@ Alternatively, you can run
 
 ::
 
-    $ scons p=ios target=template_debug ios_simulator=yes arch=x86_64
-    $ scons p=ios target=template_debug ios_simulator=yes arch=arm64
+    scons platform=ios target=template_debug ios_simulator=yes arch=x86_64
+    scons platform=ios target=template_debug ios_simulator=yes arch=arm64
 
 for a Simulator libraries.
 
@@ -79,13 +79,13 @@ should be placed in ``libgodot.ios.debug.xcframework`` and ``libgodot.ios.releas
 
 ::
 
-    $ cp -r misc/dist/ios_xcode .
+    cp -r misc/dist/ios_xcode .
 
-    $ cp libgodot.ios.template_debug.arm64.a ios_xcode/libgodot.ios.debug.xcframework/ios-arm64/libgodot.a
-    $ lipo -create libgodot.ios.template_debug.arm64.simulator.a libgodot.ios.template_debug.x86_64.simulator.a -output ios_xcode/libgodot.ios.debug.xcframework/ios-arm64_x86_64-simulator/libgodot.a
+    cp libgodot.ios.template_debug.arm64.a ios_xcode/libgodot.ios.debug.xcframework/ios-arm64/libgodot.a
+    lipo -create libgodot.ios.template_debug.arm64.simulator.a libgodot.ios.template_debug.x86_64.simulator.a -output ios_xcode/libgodot.ios.debug.xcframework/ios-arm64_x86_64-simulator/libgodot.a
 
-    $ cp libgodot.ios.template_release.arm64.a ios_xcode/libgodot.ios.release.xcframework/ios-arm64/libgodot.a
-    $ lipo -create libgodot.ios.template_release.arm64.simulator.a libgodot.ios.template_release.x86_64.simulator.a -output ios_xcode/libgodot.ios.release.xcframework/ios-arm64_x86_64-simulator/libgodot.a
+    cp libgodot.ios.template_release.arm64.a ios_xcode/libgodot.ios.release.xcframework/ios-arm64/libgodot.a
+    lipo -create libgodot.ios.template_release.arm64.simulator.a libgodot.ios.template_release.x86_64.simulator.a -output ios_xcode/libgodot.ios.release.xcframework/ios-arm64_x86_64-simulator/libgodot.a
 
 The MoltenVK static ``.xcframework`` folder must also be placed in the ``ios_xcode``
 folder once it has been created.

contributing/development/compiling/compiling_for_windows.rst

@@ -314,7 +314,7 @@ codebase. To edit projects with Visual Studio they need to be set up as a soluti
 You can create a Visual Studio solution via SCons by running SCons with
 the ``vsproj=yes`` parameter, like this::
 
-   scons p=windows vsproj=yes
+   scons platform=windows vsproj=yes
 
 You will be able to open Godot's source in a Visual Studio solution now,
 and able to build Godot using Visual Studio's **Build** button.

contributing/development/compiling/compiling_with_dotnet.rst

@@ -46,7 +46,7 @@ the desired targets without having to repeat this process.
 ``<godot_binary>`` refers to the editor binary you compiled with the .NET module
 enabled. Its exact name will differ based on your system and configuration, but
 should be of the form ``bin/godot.<platform>.editor.<arch>.mono``, e.g.
-``bin/godot.linuxbsd.editor.x86_64.mono`` or 
+``bin/godot.linuxbsd.editor.x86_64.mono`` or
 ``bin/godot.windows.editor.x86_32.mono.exe``. Be especially aware of the
 **.mono** suffix! If you've previously compiled Godot without .NET support, you
 might have similarly named binaries without this suffix. These binaries can't be
@@ -149,11 +149,11 @@ Example (Windows)
 ::
 
     # Build editor binary
-    scons p=windows target=editor module_mono_enabled=yes
+    scons platform=windows target=editor module_mono_enabled=yes
     # Build export templates
-    scons p=windows target=template_debug module_mono_enabled=yes
-    scons p=windows target=template_release module_mono_enabled=yes
-    
+    scons platform=windows target=template_debug module_mono_enabled=yes
+    scons platform=windows target=template_release module_mono_enabled=yes
+
     # Generate glue sources
     bin/godot.windows.editor.x86_64.mono --headless --generate-mono-glue modules/mono/glue
     # Build .NET assemblies
@@ -166,10 +166,10 @@ Example (Linux, \*BSD)
 ::
 
     # Build editor binary
-    scons p=linuxbsd target=editor module_mono_enabled=yes
+    scons platform=linuxbsd target=editor module_mono_enabled=yes
     # Build export templates
-    scons p=linuxbsd target=template_debug module_mono_enabled=yes
-    scons p=linuxbsd target=template_release module_mono_enabled=yes
+    scons platform=linuxbsd target=template_debug module_mono_enabled=yes
+    scons platform=linuxbsd target=template_release module_mono_enabled=yes
 
     # Generate glue sources
     bin/godot.linuxbsd.editor.x86_64.mono --headless --generate-mono-glue modules/mono/glue

contributing/development/core_and_modules/custom_modules_in_cpp.rst

@@ -547,7 +547,7 @@ main ``doc/classes`` directory.
     You can use Git to check if you have missed some of your classes by checking the
     untracked files with ``git status``. For example::
 
-        user@host:~/godot$ git status
+        git status
 
     Example output::
 
@@ -573,7 +573,7 @@ Run command:
 
    ::
 
-      user@host:~/godot$ ./bin/<godot_binary> --doctool .
+      bin/<godot_binary> --doctool .
 
 Now if you go to the ``godot/modules/summator/doc_classes`` folder, you will see
 that it contains a ``Summator.xml`` file, or any other classes, that you referenced

contributing/development/debugging/index.rst

@@ -28,7 +28,7 @@ For example, using ``gdb`` directly, you may do this:
 
 .. code-block:: none
 
-    $ gdb godot
+    gdb godot
     > run -e --path ~/myproject
 
 You can also run the editor directly from your project's folder. In that case,
@@ -36,8 +36,8 @@ only the ``-e`` option is required.
 
 .. code-block:: none
 
-    $ cd ~/myproject
-    $ gdb godot
+    cd ~/myproject
+    gdb godot
     > run -e
 
 You can learn more about these launch options and other command line arguments

contributing/workflow/bisecting_regressions.rst

@@ -131,7 +131,7 @@ Example usage:
 
 .. code-block:: shell
 
-    $ gd_snapshot_commit 4.0 beta4
+    gd_snapshot_commit 4.0 beta4
 
 To refer to the latest state of the master branch, you can use ``master``
 instead of a commit hash. Note that unlike tagged releases or snapshot commit
@@ -148,15 +148,15 @@ folder and enter the following command:
 
     # <good commit hash> is hash of the build that works as expected.
     # <bad commit hash> is hash of the build exhibiting the bug.
-    $ git bisect start
-    $ git bisect good <good commit hash>
-    $ git bisect bad <bad commit hash>
+    git bisect start
+    git bisect good <good commit hash>
+    git bisect bad <bad commit hash>
 
 Compile Godot. This assumes you've set up a build environment:
 
 .. code-block:: shell
 
-    $ scons
+    scons
 
 Run the engine
 ^^^^^^^^^^^^^^
@@ -173,13 +173,13 @@ If the build **still** exhibits the bug, run the following command:
 
 .. code-block:: shell
 
-    $ git bisect bad
+    git bisect bad
 
 If the build **does not** exhibit the bug, run the following command:
 
 .. code-block:: shell
 
-    $ git bisect good
+    git bisect good
 
 After entering one of the commands above, Git will switch to a different commit.
 You should now build Godot again, try to reproduce the bug, then enter ``git

contributing/workflow/pr_workflow.rst

@@ -95,7 +95,7 @@ To clone your fork from GitHub, use the following command:
 
 ::
 
-    $ git clone https://github.com/USERNAME/godot
+    git clone https://github.com/USERNAME/godot
 
 .. note:: In our examples, the "$" character denotes the command line prompt
           on typical UNIX shells. It is not part of the command and should
@@ -106,14 +106,14 @@ working directory. Move into it using the ``cd`` command:
 
 ::
 
-    $ cd godot
+    cd godot
 
 We will start by setting up a reference to the original repository that we forked:
 
 ::
 
-    $ git remote add upstream https://github.com/godotengine/godot
-    $ git fetch upstream
+    git remote add upstream https://github.com/godotengine/godot
+    git fetch upstream
 
 This will create a reference named ``upstream`` pointing to the original
 ``godotengine/godot`` repository. This will be useful when you want to pull new
@@ -149,30 +149,30 @@ a feature branch:
 ::
 
     # Create the branch based on the current branch (master)
-    $ git branch better-project-manager
+    git branch better-project-manager
 
     # Change the current branch to the new one
-    $ git checkout better-project-manager
+    git checkout better-project-manager
 
 This command is equivalent:
 
 ::
 
     # Change the current branch to a new named one, based on the current branch
-    $ git checkout -b better-project-manager
+    git checkout -b better-project-manager
 
 If you want to go back to the ``master`` branch, you'd use:
 
 ::
 
-    $ git checkout master
+    git checkout master
 
 You can see which branch you are currently on with the ``git branch``
 command:
 
 ::
 
-    $ git branch
+    git branch
       2.1
     * better-project-manager
       master
@@ -183,7 +183,7 @@ you can specify a custom base branch after the new branch's name:
 
 ::
 
-    $ git checkout -b my-new-feature master
+    git checkout -b my-new-feature master
 
 Updating your branch
 --------------------
@@ -200,7 +200,7 @@ current upstream ``master`` branch, you will have to update your branch by
 
 ::
 
-    $ git pull --rebase upstream master
+    git pull --rebase upstream master
 
 The ``--rebase`` argument will ensure that any local changes that you committed
 will be re-applied *on top* of the pulled branch, which is usually what we want
@@ -296,32 +296,32 @@ Here's how the shell history could look like on our example:
 ::
 
     # It's nice to know where you're starting from
-    $ git log
+    git log
 
     # Do changes to the Project Manager with the nano text editor
-    $ nano editor/project_manager.cpp
+    nano editor/project_manager.cpp
 
     # Find an unrelated bug in Control and fix it
-    $ nano scene/gui/control.cpp
+    nano scene/gui/control.cpp
 
     # Review changes
-    $ git status
-    $ git diff
+    git status
+    git diff
 
     # We'll do two commits for our unrelated changes,
     # starting by the Control changes necessary for the PM enhancements
-    $ git add scene/gui/control.cpp
-    $ git commit -m "Fix handling of margins in Control"
+    git add scene/gui/control.cpp
+    git commit -m "Fix handling of margins in Control"
 
     # Check we did good
-    $ git log
-    $ git show
-    $ git status
+    git log
+    git show
+    git status
 
     # Make our second commit
-    $ git add editor/project_manager.cpp
-    $ git commit -m "Add a pretty banner to the Project Manager"
-    $ git log
+    git add editor/project_manager.cpp
+    git commit -m "Add a pretty banner to the Project Manager"
+    git log
 
 With this, we should have two new commits in our ``better-project-manager``
 branch which were not in the ``master`` branch. They are still only local
@@ -337,7 +337,7 @@ remote branch to share them with the world. The syntax for this is:
 
 ::
 
-    $ git push <remote> <local branch>[:<remote branch>]
+    git push <remote> <local branch>[:<remote branch>]
 
 The part about the remote branch can be omitted if you want it to have the
 same name as the local branch, which is our case in this example, so we will
@@ -345,7 +345,7 @@ do:
 
 ::
 
-    $ git push origin better-project-manager
+    git push origin better-project-manager
 
 Git will ask you for your username and password. For your password, enter your
 GitHub Personal Access Token (PAT). If you do not have a GitHub Personal Access
@@ -394,13 +394,13 @@ branch, push it to your fork, and the PR will be updated automatically:
 ::
 
     # Check out your branch again if you had changed in the meantime
-    $ git checkout better-project-manager
+    git checkout better-project-manager
 
     # Fix a mistake
-    $ nano editor/project_manager.cpp
-    $ git add editor/project_manager.cpp
-    $ git commit -m "Fix a typo in the banner's title"
-    $ git push origin better-project-manager
+    nano editor/project_manager.cpp
+    git add editor/project_manager.cpp
+    git commit -m "Fix a typo in the banner's title"
+    git push origin better-project-manager
 
 However, be aware that in our PR workflow, we favor commits that bring the
 codebase from one functional state to another functional state, without having
@@ -413,17 +413,17 @@ fixes. The above example would then become:
 ::
 
     # Check out your branch again if you had changed in the meantime
-    $ git checkout better-project-manager
+    git checkout better-project-manager
 
     # Fix a mistake
-    $ nano editor/project_manager.cpp
-    $ git add editor/project_manager.cpp
+    nano editor/project_manager.cpp
+    git add editor/project_manager.cpp
     # --amend will change the previous commit, so you will have the opportunity
     # to edit its commit message if relevant.
-    $ git commit --amend
+    git commit --amend
     # As we modified the last commit, it no longer matches the one from your
     # remote branch, so we need to force push to overwrite that branch.
-    $ git push --force origin better-project-manager
+    git push --force origin better-project-manager
 
 .. Kept for compatibility with the previous title, linked in many PRs.
 
@@ -460,7 +460,7 @@ upstream ``master`` branch, which you can do with:
 
 ::
 
-    $ git rebase -i upstream/master
+    git rebase -i upstream/master
 
 .. note:: Referencing branches in Git is a bit tricky due to the distinction
           between remote and local branches. Here, ``upstream/master`` (with a
@@ -511,7 +511,7 @@ will raise an error:
 
 ::
 
-    $ git push origin better-project-manager
+    git push origin better-project-manager
     To https://github.com/akien-mga/godot
      ! [rejected]        better-project-manager -> better-project-manager (non-fast-forward)
     error: failed to push some refs to 'https://akien-mga@github.com/akien-mga/godot'
@@ -524,7 +524,7 @@ will have to *force* it:
 
 ::
 
-    $ git push --force origin better-project-manager
+    git push --force origin better-project-manager
 
 And tadaa! Git will happily *replace* your remote branch with what you had
 locally (so make sure that's what you wanted, using ``git log``). This will
@@ -543,7 +543,7 @@ the following steps *should* fix this in one step:
 
 .. code-block:: text
 
-    $ git rebase -i --onto master 4.2
+    git rebase -i --onto master 4.2
 
 This will take all the commits on your branch *after* the ``4.2`` branch, and then splice them on top of ``master``,
 ignoring any commits from the ``4.2`` branch not on the ``master`` branch. You may still need to do some fixing, but
@@ -553,7 +553,7 @@ Just like above for the interactive rebase you need to force push your branch to
 
 ::
 
-    $ git push --force origin better-project-manager
+    git push --force origin better-project-manager
 
 Deleting a Git branch
 ---------------------
@@ -567,7 +567,7 @@ To delete our better Project Manager branch locally, use this command:
 
 ::
 
-    $ git branch -d better-project-manager
+    git branch -d better-project-manager
 
 Alternatively, if the branch hadn't been merged yet and we wanted to delete it anyway, instead
 of ``-d`` you would use ``-D``.
@@ -576,7 +576,7 @@ Next, to delete the remote branch on GitHub use this command:
 
 ::
 
-    $ git push origin -d better-project-manager
+    git push origin -d better-project-manager
 
 You can also delete the remote branch from the GitHub PR itself, a button should appear once
 it has been merged or closed.

contributing/workflow/testing_pull_requests.rst

@@ -119,19 +119,19 @@ Alternatively, you can checkout the pull request directly with git:
 
 ::
 
-    $ git fetch upstream pull/PR_NUMBER/head:BRANCH_NAME
+    git fetch upstream pull/PR_NUMBER/head:BRANCH_NAME
 
 So for the pull request above, the actual command will be:
 
 ::
 
     # Fetch PR branch locally
-    $ git fetch upstream pull/48734/head:editor_file_dialog_filter_sort
+    git fetch upstream pull/48734/head:editor_file_dialog_filter_sort
 
 - Once the pull request finishes downloading, checkout its branch:
 
 ::
 
-    $ git checkout editor_file_dialog_filter_sort
+    git checkout editor_file_dialog_filter_sort
 
 - And follow the :ref:`compiling <toc-devel-compiling>` instructions for your operating system.

tutorials/assets_pipeline/import_process.rst

@@ -84,7 +84,7 @@ files contain important metadata.
 
 ::
 
-    $ ls
+    ls
     example.png
     example.png.import
     project.godot
@@ -94,7 +94,7 @@ Additionally, extra assets will be present in the hidden
 
 ::
 
-    $ ls .godot/imported
+    ls .godot/imported
     example.png-218a8f2b3041327d8a5756f3a245f83b.ctex
     example.png-218a8f2b3041327d8a5756f3a245f83b.md5