rbt 0.8.112 → 0.10.141

data/bin/{symlink_this_program → all_urls}

@@ -2,6 +2,6 @@
 # Encoding: UTF-8
 # frozen_string_literal: true
 # =========================================================================== #
-require 'rbt/symlink_this_program/initialize.rb'
+require 'rbt/cookbooks/all_urls.rb'
 
-RBT::SymlinkThisProgram.new(ARGV) # rnsymc
+RBT::Cookbooks::AllUrls.new(ARGV)

data/bin/cookbooks

@@ -4,8 +4,8 @@
 # =========================================================================== #
 require 'rbt/requires/require_the_cookbook_class.rb'
 
-RBT::Cookbooks::Cookbook.new(ARGV)
-# _ = RBT::Cookbooks::Cookbook.new(ARGV, :dont_run_yet)
+RBT::Cookbooks::SanitizeCookbook.new(ARGV) { :fast }
+# _ = RBT::Cookbooks::SanitizeCookbook.new(ARGV, :dont_run_yet)
 # _.menu(ARGV)
 # _.set_be_verbose
 # _.full_report

data/bin/create_html_page_for_these_programs

@@ -2,6 +2,6 @@
 # Encoding: UTF-8
 # frozen_string_literal: true
 # =========================================================================== #
-require 'rbt/toplevel_methods/create_html_page_for_these_programs.rb'
+require 'rbt/toplevel_methods/html.rb'
 
 RBT.create_html_page_for_these_programs(ARGV)

data/{test/testing_determine_archive_type.rb → bin/feedback_all_available_formats}

@@ -2,8 +2,6 @@
 # Encoding: UTF-8
 # frozen_string_literal: true
 # =========================================================================== #
-require 'rbt/determine_archive_type/determine_archive_type.rb'
+require 'rbt'
 
-include RBT
-
-puts DetermineArchiveType['htop-1.2.0.tar.xz']
+RBT::Cookbooks::SanitizeCookbook.feedback_all_available_formats

data/bin/feedback_description_of

@@ -2,6 +2,6 @@
 # Encoding: UTF-8
 # frozen_string_literal: true
 # =========================================================================== #
-require 'rbt/cookbooks/cookbook/cookbook.rb'
+require 'rbt/requires/require_the_cookbook_class.rb'
 
 RBT::Cookbooks::FeedbackDescriptionOf.new(ARGV)

data/bin/find_url_for

@@ -0,0 +1,7 @@
+#!/usr/bin/ruby -w
+# Encoding: UTF-8
+# frozen_string_literal: true
+# =========================================================================== #
+require 'rbt/toplevel_methods/url.rb'
+
+RBT.find_url_for(ARGV)

data/bin/rbt

@@ -18,7 +18,7 @@ else
     RBT.report_rbt_version(:also_show_when_the_project_was_last_updated)
     exit
   else # this is the default clause.
-    require 'rbt/commandline/commandline.rb'
-    RBT::Commandline.new(ARGV)
+    require 'rbt/commandline/parse_the_commandline.rb'
+    RBT::ParseTheCommandline.new(ARGV)
   end
 end

data/bin/store_abbreviations

@@ -0,0 +1,7 @@
+#!/usr/bin/ruby -w
+# Encoding: UTF-8
+# frozen_string_literal: true
+# =========================================================================== #
+require 'rbt/toplevel_methods/available_programs.rb'
+
+RBT.store_abbreviations

data/bin/symlink_from_to_current

@@ -0,0 +1,7 @@
+#!/usr/bin/ruby -w
+# Encoding: UTF-8
+# frozen_string_literal: true
+# =========================================================================== #
+require 'rbt/utility_scripts/symlink_from_to_current/symlink_from_to_current.rb'
+
+RBT::SymlinkFromToCurrent.new(ARGV) # rnsymc

data/doc/COOKBOOK_CONVENTIONS.md

@@ -381,6 +381,8 @@
 #                                       # but the user.05.give us another 
 #                                       # build directory. I no longer use this setting,
 #                                       # but I will keep it, maybe others need it.
+# =========================================================================== #
+
 # =========================================================================== #
 # === MANDATORY ENTRIES
 #
@@ -389,7 +391,11 @@
 # setting.
 #
 # There is only one mandatory entry so far, and this is:
+#
 #   program_name
+#
+# =========================================================================== #
+
 # =========================================================================== #
 # These are NOT or NO LONGER mandatory entries:
 #

data/doc/README.gen

@@ -191,7 +191,7 @@ decade, really. I can not even pinpoint to a single year when the RBT
 project was started, since it started out as a set of semi-random .rb
 files/scripts, but I think the rbt project was created, through
 the old cookbooks project, in the year **2005**, give or take. The
-file called **COOKBOOK_STATISTICS.md** keeps some old entries. For
+file called **cookbook_statistics.md** keeps some old entries. For
 example, in late October in the year **2005**, the old Cookbooks project,
 which was eventually changed into RBT, already had **274 programs registered**,
 so it had to have been started prior to October 2005. For comparison -
@@ -399,7 +399,7 @@ curl or wget to check if such a remote tarball exists.
 If it exists it is downloaded. I can then compile it by
 simply issuing:
 
-    ry php
+    rbt php
 
 And if things go ok (which they tend to do, at the least for
 php and many other programs that can be compiled), then php
@@ -457,9 +457,9 @@ now. I want to be better prepared before I rewrite it.)
 I can compile most of the programs that are listed in RBT
 via:
 
-    ry NAME
-    ry php
-    ry python
+    rbt NAME
+    rbt php
+    rbt python
 
 and so forth, so this is really convenient. I don't depend on
 another package manager that upstream developers control.
@@ -528,17 +528,18 @@ and things will (should) work past this point - but I can also
 override the settings from the commandline, so I have all the
 flexibility required available.
 
-In many ways I thus control most aspects via these individual
-.yml files. Other package managers do something similar if you
-look at them. Arch, for instance, uses PKG_BUILD or some file
-like th at; gentoo uses ebuilds, and so forth.
-
-The "default settings" that I may use go into such a specific .yml
-file, whereas the **commandline switches** allow me to specifically
-override or cherry-pick other settings, based on the machine
-that I am working with. For example, on **GoboLinux** the
-AppDir prefix makes a lot of sense. On **slackware** on the other
-hand I may decide to just use **/usr** as option given
+This, in turn, means that I control most of what I compile via
+.yml files, first and foremost - a text file. Other package managers
+do something similar if you look at them. Arch, for instance,
+uses PKG_BUILD or some file like that; gentoo uses ebuilds,
+debian also uses some designated files, and so forth.
+
+The "default settings" that I may use for these programs go into 
+a specific .yml file, whereas the **commandline switches** allow
+me to specifically override or cherry-pick other settings, based
+on the machine that I am working with. For example, on **GoboLinux**
+the AppDir prefix makes a lot of sense. On **slackware** on the
+other hand I may decide to just use **/usr** as option given
 to **--prefix=**.
 
 On **traditional** linux distributions, **/usr** as prefix is
@@ -547,8 +548,8 @@ compile into the **user's home directory**. A commandline switch
 exists for the latter, for the RBT project, called **--home-directory**.
 This is equivalent to whatever the user's home directory ought to
 be, such as **/home/debug/** or **/home/joe/**. (I typically have
-a user account called **debug** on my systems, which are mostly
-for debugging-related activities.)
+a user account called **debug** on my systems, which is mostly
+concerned with debugging something on the target computer.)
 
 So, --home-directory for the user joe would be equivalent to
 **--prefix=/home/joe/**.
@@ -886,18 +887,18 @@ a new URL and register a program this way anew.
 
 Commandline Example for this:
 
-    ry http://ftp.gnu.org/pub/gnu/kawa/kawa-3.1.tar.gz
+    rbt http://ftp.gnu.org/pub/gnu/kawa/kawa-3.1.tar.gz
 
 ## /home/Programs/ versus /Programs/
 
-On GoboLinux, the main application directory is at /Programs/.
+On GoboLinux, the main application directory is at **/Programs/**.
 
-For RBT, the default since a few years is /home/Programs/. Now -
-the user can set any other application directory anyway, so
-this subsection explains mostly my own use case.
+For RBT, the default since a few years is **/home/Programs/**.
+Now - the user can set any other application directory anyway,
+so this subsection explains mostly my own use case.
 
-I was following the /Programs/ hierarchy for some years, but
-eventually changed to /home/Programs/.
+I was following the **/Programs/** hierarchy for some years,
+but eventually changed to **/home/Programs/**.
 
 There are two reasons as to why:
 
@@ -1050,10 +1051,10 @@ within the **/opt/** hierarchy.
 
 Or use the more prevalent rbt name:
 
-    ry --permanently-set-base-directory-to=/Mount/USB1/last_backup/src/
-    ry --permanently-set-source-archive=/Mount/USB1/last_backup/src/
-    ry --set-source-dir=/Mount/USB1/last_backup/src/
-    ry --set-source-dir==/Files/Archive/
+    rbt --permanently-set-base-directory-to=/Mount/USB1/last_backup/src/
+    rbt --permanently-set-source-archive=/Mount/USB1/last_backup/src/
+    rbt --set-source-dir=/Mount/USB1/last_backup/src/
+    rbt --set-source-dir==/Files/Archive/
 
 The above would assume that all source archives will be stored
 within the **/Mount/USB1/last_backup/src/** hierarchy.
@@ -1061,7 +1062,7 @@ within the **/Mount/USB1/last_backup/src/** hierarchy.
 Since as of April 2019, the following shorter variant can also be used
 instead:
 
-    ry --source-dir=/SRC
+    rbt --source-dir=/SRC
 
 I added this primarily because typing the longer variants above, on a
 freshly set-up computer, is somewhat cumbersome. So the shorter variant
@@ -1137,8 +1138,8 @@ Take note that you can enable this functionality also through **bin/rbt**
 (aka **rbt** on the commandline) as well, such as in the **following
 examples**:
 
-    ry --scookie=glib
-    ry --scookie=htop
+    rbt --scookie=glib
+    rbt --scookie=htop
 
 The associated .yml file is always available anyway, with or without the
 archive being available locally as well. So you can always query the
@@ -1203,7 +1204,7 @@ commandline by issuing any of the following:
 The number of registered programs can be queried via the
 commandline as well, like in this way:
 
-    ry --n_programs?
+    rbt --n_programs?
 
 Although the output may be a little bit different.
 
@@ -1385,7 +1386,7 @@ something via the RBT scripts.
 Let's start with "htop" as example, a useful program written by
 one of the original creators of the **GoboLinux** project:
 
-    ry htop
+    rbt htop
 
 This should, if everything works fine, download htop, extract
 and compile it.
@@ -1396,9 +1397,9 @@ If you wish to use another prefix, such as:
 
 you can do this:
 
-    ry htop --appdir
-    ry htop non-traditional
-    ry htop ntrad
+    rbt htop --appdir
+    rbt htop non-traditional
+    rbt htop ntrad
 
 ntrad stands for "non-traditional". Note that the entry is **NOT**
 hardcoded towards **/Programs/** - you can define your own app-dir
@@ -1433,9 +1434,9 @@ long words and consider using abbreviations instead. :)
 
 Anyway, here is the example to use **/usr** as prefix:
 
-    ry htop --traditional
-    ry htop --trad
-    ry htop trad
+    rbt htop --traditional
+    rbt htop --trad
+    rbt htop trad
 
 Use any variant there. I prefer the last one, "trad", because
 it is shorter to type.
@@ -1443,7 +1444,7 @@ it is shorter to type.
 If you wish to look at the available help options that are
 available for rbt, do:
 
-    ry --help
+    rbt --help
 
 Note that this will showcase mostly just the more common
 ones. There are many more options that can be used.
@@ -1492,7 +1493,7 @@ test it too though if you enable "is_on_roebe".
 If you wish to find all registered programs that start with
 a specific letter, such as k, do this:
 
-    ry k*
+    rbt k*
 
 This will output all programs that start with k and also
 tell you how many programs with that letter exist.
@@ -1520,7 +1521,7 @@ before (meaning that RBT has stored the configure command used
 in that .yml ile) - say, the program <b>attica</b> was compiled,
 then you can query this information from the commandline, via:
 
-    ry attica --show-last-configure-option
+    rbt attica --show-last-configure-option
 
 This could then be used to copy/paste, or modify if you experience
 some problems related to compiling a program from source, for
@@ -1552,14 +1553,16 @@ functionality at the least exists as part of <b>RBT::Compile</b>.
 The time it took, in seconds, will also be stored in the file
 called <b>database_storing_compile_times.yml</b>, in a simple key-value
 hash. (This file will be generated into the <b>rbt_logs/</b>
-subdirectory.)
+subdirectory.
+On my home system this file will thus be at 
+**/home/Temp/rbt/database_storing_compile_times.yml**)
 
 If you compiled several programs via rbt, you can also show how 
 long it took to compile these programs.
 
 The commandline option for this is:
 
-    ry --show-compile-time-statistics
+    rbt --show-compile-time-statistics
 
 ## systemd
 
@@ -1616,7 +1619,7 @@ and then wish to autogenerate a new expanded cookbook
 dataset, then you can use this commandline switch from
 within rbt to do so, too:
 
-    ry --create-yaml-file-for=subversion
+    rbt --create-yaml-file-for=subversion
 
 This requires the cookbooks gem to be installed.
 
@@ -1648,7 +1651,7 @@ You can modify the $PATH setting for rbt too at runtime.
 For example, to prioritize on <b>/usr/bin/</b>, you can use
 this commandline switch:
 
-    ry --traditional-path
+    rbt --traditional-path
 
 Of course you can also change the $PATH variable on your own
 permanently - environment variables are in general available
@@ -1685,8 +1688,8 @@ If you wish to find out the current **source directory** used by
 **RBT** then you can use either one of the following commandline
 flags:
 
-    ry --source-dir?
-    ry --source-archive?
+    rbt --source-dir?
+    rbt --source-archive?
 
 ## Prefixes to use
 
@@ -1705,13 +1708,13 @@ on university clusters.
 Some convenient shortcuts exist here, in order to make working with
 prefixes simpler:
 
-    ry m4 ULOCAL
+    rbt m4 ULOCAL
 
 This will use the **--prefix=/usr/local/** setting, so it is
 <b>exactly</b> the same as if you would have been issuing this
 instruction:
 
-    ry m4 --prefix=/usr/local/
+    rbt m4 --prefix=/usr/local/
 
 So the only real benefit of using upcased ULOCAL is that you save
 a few keystrokes - which is a real benefit for people who like
@@ -1727,7 +1730,7 @@ other settings.
 
 Let's look at another example:
 
-    ry m4 --opt_prefix
+    rbt m4 --opt_prefix
 
 This will use **--prefix=/opt/**.
 
@@ -1735,13 +1738,13 @@ If you want to, you can also compile into your $HOME directory
 and build up an AppDir layout; this is how **GoboLinux** has
 been created actually, a long time ago:
 
-    ry htop --appdir-into-home-dir
+    rbt htop --appdir-into-home-dir
 
 If you only wish to compile into the home directory, without
 using the AppDir approach, then you can use the following
 invocation:
 
-    ry htop --compile-into-home-dir
+    rbt htop --compile-into-home-dir
 
 Do note that since as of the 26.01.2019 (26th January 2019) you
 can also use **RBT::CompileIntoHomeDir.new** if you wish to
@@ -1753,7 +1756,7 @@ into your home dir, via proper prefix, you could use:
 
 This is functionally equivalent to:
 
-   ry htop --prefix=/root/
+   rbt htop --prefix=/root/
 
 if you are the **superuser**; and if you are a regular user then of
 course it will use your default **HOME_DIR** setting (usually
@@ -1786,7 +1789,7 @@ or **--noprefix**.
 
 Example:
 
-    ry htop --noprefix
+    rbt htop --noprefix
 
 ## Determine how many core/processors the computer has
 
@@ -1794,8 +1797,8 @@ If you wish to find out how many processors/core a target
 machine has, you can use any of the following two invocation
 examples:
 
-     ry --n-processors?
-     ry --n-cores?
+    rbt --n-processors?
+    rbt --n-cores?
 
 The code for this resides in the method
 **try_to_output_how_many_processors_this_computer_has**, which
@@ -1877,35 +1880,6 @@ To set a new **global prefix**, do something like this:
 
     set_prefix=/usr/local
 
-## ccache
-
-There is a configuration setting, <b>use_ccache</b>, which, when
-enabled, attempts to **make use of ccache for compilation**.
-
-This may speed up repeated compilation cycles of the same program
-quite efficiently.
-
-If you do not need ccache or do not have it, you can disable the use
-of ccache permanently, as far as RBT is concerned, via:
-
-    ry --permanently-disable-ccache
-
-Alternatively you can also modify the file
-<b>rbt/yaml/configuration/use_ccache.yml</b>, which is
-where the configuration setting as to whether to use
-ccache or not, resides. The allowed values are
-<b>true</b> or <b>false</b>, <b>yes</b> and <b>no</b> (for
-all configuration values, by the way).
-
-If you only want to **disable ccache for the current run**, then you can
-use any of the following variants (here we assume that the target program
-you wish to compile is <b>fluxbox</b>):
-
-    ry fluxbox --disable-ccache 
-    ry fluxbox --do-not-use-ccache
-    ry fluxbox --no-ccache
-    ry fluxbox --ccache-
-
 ## Auto-resolve compile-related problems
 
 Note that since as of September 2017, the **RBT scripts** can also
@@ -1954,10 +1928,10 @@ You can also invoke this from the commandline, of course.
 
 Usage examples for the commandline invocation:
 
-    ry --check-for-binary-duplicates
-    ry --binary-duplicates
-    ry --report-binary-duplicates
-    ry --report-duplicates
+    rbt --check-for-binary-duplicates
+    rbt --binary-duplicates
+    rbt --report-binary-duplicates
+    rbt --report-duplicates
 
 ## Future Goals
 
@@ -2099,12 +2073,12 @@ The following command should suffice - but **review this list on your own
 before you use it**; as a first step, it may be simpler to compile
 step-by-step, rather than all in one giant step.
 
-    ry make sed awk coreutils utillinux gawk m4
+    rbt make sed awk coreutils utillinux gawk m4
 
 (Note that the above may no longer work; you may have to be more
 explicit like so:)
 
-    ry --compile-these-programs=make,sed,awk,coreutils,utillinux,gawk,m4
+    rbt --compile-these-programs=make,sed,awk,coreutils,utillinux,gawk,m4
 
 I recommend that, if possible, compile as many of these programs
 as a static binary. That way, if you somehow break a dependent
@@ -2124,10 +2098,10 @@ example).
 
 Invocation examples:
 
-    ry mpfr
-    ry gmp
-    ry mpcr
-    ry gcc
+    rbt mpfr
+    rbt gmp
+    rbt mpcr
+    rbt gcc
 
 Keep in mind that you can also use the LFS/BLFS instructions.
 They are also available via the "blfs" entry in the respective
@@ -2143,7 +2117,7 @@ it yet.
 
 An invocation example follows here:
 
-    ry glibc ntrad --do-not-symlink
+    rbt glibc ntrad --do-not-symlink
 
 Or use another --prefix, such as /opt/glibc/2.30 or just
 /opt/glibc or your home directory.
@@ -2154,16 +2128,16 @@ us to compile the core programs here.
 
 Invoke it like so:
 
-    ry --compile-base-system
-    ry --compile-basic-system
+    rbt --compile-base-system
+    rbt --compile-basic-system
 
 The exact programs that will be compiled may change from time to
 time. If you need a commandline result of the programs that will
 be compiled that way, simply append a '?' character to the above
 way to compile the base system, such as:
 
-     ry --compile-base-system?
-     ry --compile-basic-system?
+    rbt --compile-base-system?
+    rbt --compile-basic-system?
 
 If everything works here then you should have several 
 "linux" programs under the **/Programs/** hierarchy installed.
@@ -2179,7 +2153,7 @@ Do note that RBT tries to sanitize the given input a little.
 
 For example, the following would work:
 
-    ry libcryptsetup
+    rbt libcryptsetup
 
 even though there is no program called **libcryptsetup** registered.
 The real name is actually **cryptsetup**, but the philosophy
@@ -2214,11 +2188,11 @@ You can also get an overview over the programs that make
 use of a build directory, by using any of the following
 APIs on the commandline:
 
-    ry --show-all-programs-that-make-use-of-a-build-directory
-    ry --all-build-directory
-    ry --all-build-directories
-    ry --build-directories?
-    ry --build-directories
+    rbt --show-all-programs-that-make-use-of-a-build-directory
+    rbt --all-build-directory
+    rbt --all-build-directories
+    rbt --build-directories?
+    rbt --build-directories
 
 ## RBT project will install these executables
 
@@ -2233,12 +2207,12 @@ You can try to update some of the **mate-desktop components**.
 
 In order to do this, call either of the following variants.
 
-    ry --update-mate
-    ry --update-mate-desktop
-    ry --check-for-mate-updates
-    ry --check-for-mate-desktop-updates
-    ry --check-for-mate-desktop
-    ry --check-for-matedesktop
+    rbt --update-mate
+    rbt --update-mate-desktop
+    rbt --check-for-mate-updates
+    rbt --check-for-mate-desktop-updates
+    rbt --check-for-mate-desktop
+    rbt --check-for-matedesktop
 
 The first variant is the **shortest**, whereas the second one is
 the main entry point in the **case/when** setup.
@@ -2257,60 +2231,20 @@ registered name of the mate-desktop component.
 
 Invocation example:
 
-    ry mate1
-    ry mate2
-    ry mate3
-    ry mate4
+    rbt mate1
+    rbt mate2
+    rbt mate3
+    rbt mate4
 
 This is the very same as doing e. g.:
 
-    ry mate-desktop
-    ry libmatemixer
+    rbt mate-desktop
+    rbt libmatemixer
 
 and so on. Using **numbers** may be simpler, though, as you do not
 have to remember the names as-is, while still being able to use
 the correct compilation order.
 
-## GNOME
-
-The gnome-project tarball archives can be found here:
-
-    http://ftp.gnome.org/pub/gnome/sources/?C=M;O=D
-
-The releases usually have even numbers for stable releases; and
-odd numbers for unstable releases.
-
-I myself usually stayed on the "bleeding edge", that is to use
-unstable releases - but after some time, I now think that the stable
-releases are better, since you will have less problems or errors in
-the long run. Every time I encountered a problem related to an
-unstable release, I ended up investing time trying to fix the
-problem, which often was not possible. In the end I did waste too
-much time for too little gain, so I decided to stop making use of
-unstable gnome releases.
-
-I added some code to the class that automatically downloads gnome-packages,
-to only consider **even numbers**. But this behaviour can be toggled via a
-**commandline switch** on the commandline, anyway - so the subsection here
-just explains as to why I personally **favour stable gnome releases**.
-
-You can also compile the gnome components in an ordered fashion,
-by making use of **numbers**. (This also works for kde, xfce, xorg,
-mate-desktop, games and the like.)
-
-Examples:
-
-    ry gnome1
-    ry gnome2
-    ry gnome3
-    ry gnome4
-
-And so forth.
-
-To **batch compile** most of these components, try:
-
-    ry gnome1..200
-
 ## Module programs (the extended cookbook dataset)
 
 **Module programs** refers to the ability to access all registered programs at
@@ -2378,8 +2312,8 @@ to use a simpler API. It is very easy to remember, too: just use
 You can show the last updated programs, currently, by default, being
 750 programs, like this:
 
-    ry --show-last-updated-programs
-    ry --slu
+    rbt --show-last-updated-programs
+    rbt --slu
 
 ## Auto-removing .la files
 
@@ -2442,7 +2376,7 @@ where your **temp-directory** is set at.
 You can also use **rbt** directly to remove a faulty .la
 file, by passing in the path, such as:
 
-    ry /usr/lib/libpango-1.0.la
+    rbt /usr/lib/libpango-1.0.la
 
 ## Working with (debian) .deb files
 
@@ -2485,8 +2419,8 @@ so forth (if there are several entries that is).
 If you do not need this for a given program then you can
 <b>disable</b> this behaviour on the <b>commandline</b>, via:
 
-    ry htop --disable-sed
-    ry htop --disable-sed-modifications
+    rbt htop --disable-sed
+    rbt htop --disable-sed-modifications
 
 Note that there are essentially **two** ways as to how to use 
 sed-operations, as far as <b>RBT</b> is concerned. One is by
@@ -2506,7 +2440,7 @@ under the WSL subsystem these days.
 If you want to query whether the internal sed wrapper is used
 in general, as-is, then use the following commandline option:
 
-    ry --use-the-internal-sed-wrapper?
+    rbt --use-the-internal-sed-wrapper?
 
 The sed-operations are run by class RBT::ApplySedOperations.
 This class can also be used standalone, that is, from the
@@ -2514,7 +2448,7 @@ commandline. Or you can invoke them from within rbt itself.
 
 Example:
 
-    ry htop --only-sed # only apply the sed-operations, then exit.
+    rbt htop --only-sed # only apply the sed-operations, then exit.
 
 If you wish to simply run the sed-operations registered in
 a cookbook .yml file, then you can invoke:
@@ -2529,7 +2463,7 @@ a cookbook .yml file, then you can invoke:
 If, for whatever reason, want to compile a random program, then
 you can use a commandline switch such as the following:
 
-    ry --random-program
+    rbt --random-program
 
 ## Upgrading programs through a file
 
@@ -2542,9 +2476,9 @@ another name. The file has to exist, obviously.
 
 Invocation examples:
 
-    ry --upgrade-from-this-file=these_programs_can_be_upgraded.yml
-    ry --upgrade-from-this-file=:default
-    ry --upgrade-from-this-file=:def
+    rbt --upgrade-from-this-file=these_programs_can_be_upgraded.yml
+    rbt --upgrade-from-this-file=:default
+    rbt --upgrade-from-this-file=:def
 
 :default or :def will refer to the file **these_programs_can_be_upgraded.yml**.
 
@@ -2556,8 +2490,8 @@ can auto-generate such a file, which we can then use for **RBT**.
 You can compile the dependencies of a program if you want to,
 via a commandline such as:
 
-    ry kbreakout --compile-dependencies-as-well
-    ry kbreakout --with-deps
+    rbt kbreakout --compile-dependencies-as-well
+    rbt  rbt kbreakout --with-deps
 
 Note that this will try to compile all the dependencies AND the program
 as well, with the dependencies first, and the program that was given
@@ -2576,11 +2510,11 @@ that depend on another program whose name is known.
 For example, if you wish to find out which programs all depend
 on cmake then you can use the following:
 
-    ry --show-programs-with-this-as-dependency=cmake
+    rbt --show-programs-with-this-as-dependency=cmake
 
 Likewise, to display all programs that depend on ruby, do this:
 
-    ry --show-programs-with-this-as-dependency=ruby
+    rbt  rbt --show-programs-with-this-as-dependency=ruby
 
 ## Internals of class RBT::Compile
 
@@ -2609,19 +2543,19 @@ can use numbers to compile a particular game too.
 
 For example:
 
-    ry game3
-    ry game5
-    ry game6
+    rbt game3
+    rbt game5
+    rbt game6
 
 And so forth.
 
 You can also compile all games, e. g. by doing this:
 
-    ry --compile-this-tag=games
+    rbt --compile-this-tag=games
 
 Or, even simpler:
 
-    ry --compile-all-games
+    rbt --compile-all-games
 
 (And I also did set an alias at home, to invoke
 this via **compile_all_games**).
@@ -2668,14 +2602,14 @@ If you only want to see which binaries are registered in
 all the registered programs of the RBT project, then you
 can use this commandline:
 
-    ry --all-binaries?
+    rbt --all-binaries?
 
 ## The mate-desktop
 
 If you wish to compile the components of the mate-desktop,
 you can try:
 
-    ry --compile-mate-desktop
+    rbt --compile-mate-desktop
 
 Note that this presently (July 2018) does not handle the dependencies
 correctly, so there is a very high chance of failure, unless you
@@ -2686,7 +2620,7 @@ directory, such as **/Programs/Mate/1.12/**.
 
 Issue the following command for this:
 
-    ry --mate-desktop-into-standalone-dir
+    rbt --mate-desktop-into-standalone-dir
 
 ## Purging traditional FHS binaries and FHS libraries
 
@@ -2703,8 +2637,8 @@ and then also in the respective AppDir bin/ directory.
 If you then wish to get rid of the old /usr/bin/ binary of a specific
 program, you can issue the following commands:
 
-     ry --purge-traditional-binaries-from=xscreensaver
-     ry --purge-traditional-binaries-of=gnupg
+    rbt --purge-traditional-binaries-from=xscreensaver
+    rbt --purge-traditional-binaries-of=gnupg
 
 The last entry is the program at hand, in these two examples
 **xscreensaver** or **gnugp**.
@@ -2716,8 +2650,8 @@ removal of these binaries from the commandline.
 A similar functionality exists for **libraries**. So if you want to
 purge libaries at **/usr/lib/**, you can do this:
 
-     ry --purge-traditional-libraries-from=libva
-     ry --purge-traditional-libraries-of=libva
+    rbt --purge-traditional-libraries-from=libva
+    rbt --purge-traditional-libraries-of=libva
 
 The relevant entries for binaries and libraries can be found in
 the individual .yml cookbook - have a look at the **binaries:**
@@ -2726,7 +2660,7 @@ and **libraries:** entries of the particular .yml file at hand.
 Since as of November 2018, an additional way exists to remove
 binaries:
 
-    ry poppler --purge-its-binaries
+    rbt poppler --purge-its-binaries
 
 This will currently (November 2018) only remove binaries found
 under the **/usr/bin/** hierarchy. In the future **/usr/sbin/**
@@ -2778,7 +2712,7 @@ the various programs at hands.
 If you need an overview over all registered tags, from the commandline,
 try to issue this command:          
 
-    ry --available-tags?
+    rbt --available-tags?
 
 This **only** works for programs that are installed into the **/Programs/**
 hierarchy for the time being. (Remember that /Programs/ is not hardcoded
@@ -2846,8 +2780,8 @@ or wherever you have your own particular equivalent of this main
 **Application directory** set to, then you can use the following
 **commandline switch**:
 
-    ry --remove-all-symlinks
-    ry --remove-all-symlinks
+    rbt --remove-all-symlinks
+    rbt --remove-all-symlinks
 
 (ry is an alias on my system towards rbt)
 
@@ -2862,11 +2796,11 @@ functionality.
 If you wish to instantly exit when reaching the "make install" stage,
 you can use the following commandline for this:
 
-    ry htop --stop-at-make-install-stage
+    rbt htop --stop-at-make-install-stage
 
 Something similar exists for the "make" stage:
 
-    ry htop --stop-at-make-stage
+    rbt htop --stop-at-make-stage
 
 ## class RBT::SymlinkIntoUsrLibDirectory
 
@@ -2878,10 +2812,10 @@ call from the commandline.
 By default, RBT::Compile does **not** make use of this class, but you
 can enable it via any of the following commandline flags:
 
-    ry gtk+ --symlink-into-usr-lib-dir
-    ry gtk+ --symlink-into-lib-dir
-    ry gtk+ --symlink-lib-dir
-    ry gtk+ --symlink-libs
+    rbt gtk+ --symlink-into-usr-lib-dir
+    rbt gtk+ --symlink-into-lib-dir
+    rbt gtk+ --symlink-lib-dir
+    rbt gtk+ --symlink-libs
 
 Why may this functionality be useful to have?
 
@@ -2922,8 +2856,8 @@ into the corresponding hierarchy under **/Programs/**.
 
 The commandline for this is something like:
 
-    ry libsigc++ --compile-all-available-local-versions
-    ry libsigc++ --all-available-local-versions
+    rbt libsigc++ --compile-all-available-local-versions
+    rbt libsigc++ --all-available-local-versions
 
 This is a convenience feature.
 
@@ -2948,9 +2882,9 @@ then you can invoke it like so, with another target directory:
 If you only want to check for the current working directory, you
 can use the bin/rbt executable as well, via:
 
-    ry --check-for-binary-duplicates
-    ry --check-for-duplicates
-    ry --duplicates-in-pwd?
+    rbt --check-for-binary-duplicates
+    rbt --check-for-duplicates
+    rbt --duplicates-in-pwd?
 
 ## Determine to which particular program a specific binary name belongs to
 
@@ -2958,11 +2892,11 @@ If you wish to find out to which program, e. g., the binary called
 "shar" belongs to, then you can query this from the commandline
 via:
 
-    ry --this-binary?=shar
+    rbt --this-binary?=shar
 
 Alternatively you can use this:
     
-    ry --binary=env
+    rbt --binary=env
 
 The output of these would be:
 
@@ -3044,8 +2978,8 @@ find anything).
 
 Usage examples:
 
-    ry nss  --clear-envs ntrad
-    ry nspr --clear-envs ntrad
+    rbt nss  --clear-envs ntrad
+    rbt nspr --clear-envs ntrad
 
 This would attempt to compile both nss and nspr without any environment
 variables (save for PATH).
@@ -3075,9 +3009,9 @@ create your own .yml files.
 
 Invocation examples from the commandline:
 
-    ry --suggest-cookbook-for=glib
-    ry --suggest-cookbook-for=htop
-    ry --suggest-cookbook-for=pango
+    rbt --suggest-cookbook-for=glib
+    rbt --suggest-cookbook-for=htop
+    rbt --suggest-cookbook-for=pango
 
 **Note** that this depends on these programs being installed
 in the **programs_directory?**, which on my system is equal
@@ -3097,7 +3031,7 @@ in the long run.
 
 The host system can be queried from within RBT via:
 
-    ry --host-system
+    rbt --host-system
 
 ## Inferring the build system that a particular program uses
 
@@ -3145,7 +3079,7 @@ be able to modify the .yml file, depending on the host setup (such
 as in a restricted environment like at a university campus site), a
 **commandline flag** is also available:
 
-    ry htop --disable-colours
+    rbt htop --disable-colours
 
 ## Auto-updating libraries installed under a versioned AppDir
 
@@ -3157,8 +3091,8 @@ RBT.
 If you, for any reason, wish to try to do so too, you can do
 so via any of the following invokation ways:
 
-    ry --update-libraries-of=poppler
-    ry --update-libraries-for=poppler
+    rbt --update-libraries-of=poppler
+    rbt --update-libraries-for=poppler
 
 This would then update the file called **poppler.yml**, 
 after making a backup of the old **poppler.yml** file first.
@@ -3173,6 +3107,14 @@ file.
 
 It can be found under the subdirectory **rbt/validation/**.
 
+You can also batch-invoke all validations via.
+
+    rbt --validate-entries
+
+However had, this is mostly for me, to assure quality control;
+regular users don't really need this (and it is a bit buggy
+as well).
+    
 ## The log directory
 
 The **log directory** for RBT is the directory into which RBT can
@@ -3189,8 +3131,8 @@ may typically be **/tmp/** or **/tmp/rbt/**.
 You can also generate this log directory from the commandline via
 either of the following commandline invocation ways:
 
-    ry --create-log-dir
-    ry --create-log-directory
+    rbt --create-log-dir
+    rbt --create-log-directory
 
 ## Usefulness of this project
 
@@ -3237,10 +3179,10 @@ that can be downloaded from the commandline.
 If you need to determine the URL from the commandline, you can
 try this:
 
-    ry --show-url=readline
-    ry --show-url=php
-    ry --show-url=ruby
-    ry --show-url=python
+    rbt --show-url=readline
+    rbt --show-url=php
+    rbt --show-url=ruby
+    rbt --show-url=python
 
 Note that you can also query whether a remote URL exists, if
 you have wget available.
@@ -3254,7 +3196,7 @@ Example:
 
 You can report the status of the project via:
 
-    ry --report-status
+    rbt --report-status
 
 This actually means which target directories will be used by the
 RBT project mostly.
@@ -3271,18 +3213,18 @@ like in this way:
 You can also tap into this code from the commandline, through the
 **bin/rbt** interface, such as in this way:
 
-    ry --colour_make
-    ry --colour_make_install
+    rbt --colour_make
+    rbt --colour_make_install
 
 Of course the slightly shorter variants work too:
 
-    ry --colourmake
-    ry --colourmakeinstall
+    rbt --colourmake
+    rbt --colourmakeinstall
 
 And this as well:
 
-    ry --colour-make
-    ry --colour-make-install
+    rbt --colour-make
+    rbt --colour-make-install
 
 ## RBT::ShowAllAbout
 
@@ -3300,21 +3242,21 @@ must exist, such as ruby.yml and so forth.
 
 You can also invoke the above from the commandline, by issuing:
 
-    ry --show-all-about=ruby
-    ry --show-all-about=php
+    rbt --show-all-about=ruby
+    rbt --show-all-about=php
 
 In these two cases, we would query the content of the two yaml files
 called <b>ruby.yml</b> and <b>php.yml</b>.
 
 You can also use the current working directory as "input", via:
 
-    ry --show-all-about-this-dir
+    rbt --show-all-about-this-dir
 
 For example, if the directory name is **/Depot/Temp/xcb-util-xrm-1.0/**,
 then calling rbt via the **--show-all-about-this-dir** flag will
 assume to be the same as if you would have done:
 
-    ry --show-all-about=xcb-util-xrm
+    rbt --show-all-about=xcb-util-xrm
 
 This allows you to type a little less (and not have to think about
 the name of the program at hand, since you are just using the working
@@ -3322,13 +3264,17 @@ directory as the "input" / argument).
 
 ## Running strip on binaries
 
-You can invoke the command called "strip" on binaries (executables),
-from within **rbt** too.
+You can use <b>strip</b> to reduce the size of the binaries in
+general. This is often done on programs written in the C programming
+language.
+
+You can also invoke the command called "strip" on binaries
+(**executables**), from within **rbt** too.
 
 A simple way to do so is to first navigate to a bin/ directory,
 and then invoke the following command:
 
-    ry --strip-binaries
+    rbt --strip-binaries
 
 But be careful **before** running the above - this will really
 run "strip" on every file found in the current working directory.
@@ -3338,8 +3284,16 @@ Only do so when you are sure you want to invoke **strip** there.
 You can also specifically strip only the binaries that belong
 to a certain program, such as through:
 
-    ry --strip-binaries-of=htop
+    rbt --strip-binaries-of=htop
+
+The **configuration option** called **use_strip** will determine
+whether the RBT-project does so automatically.
 
+If this configuration option is set to **true**, then we will
+run "strip --strip-unneeded" by default.
+
+On my home system this defaults to **true**.
+    
 ## Batch-downloading all source archives
 
 You can download all registered **source archives** by
@@ -3353,10 +3307,10 @@ for example:
 Alternatively, you can also **invoke the file from the commandline 
 directly, by issuing either one of the following**:
 
-    ry --download-all-source-archives
-    ry --downloadallsourcearchives
-    ry --grab-source-archives
-    ry --grabsourcearchives
+    rbt --download-all-source-archives
+    rbt --downloadallsourcearchives
+    rbt --grab-source-archives
+    rbt --grabsourcearchives
 
 From within Ruby code, you can use the following **toplevel-API**
 to download all source archives:
@@ -3398,7 +3352,7 @@ snippets in the long run, but they will not be explained in
 this subsection - see for other parts of the README.me file
 here for explanations, or use "rbt --help".
 
-    ry gdkpixbuf --home-dir --use-meson
+    rbt gdkpixbuf --home-dir --use-meson
 
 ## Show everything about a given program (show all)
 
@@ -3425,9 +3379,9 @@ A commandline variant also exists via **cookbooks** itself:
 
 Of course this works through **rbt** as well:
 
-    ry --show-all-about=htop
-    ry --show-all=htop
-    ry --show-file=htop
+    rbt --show-all-about=htop
+    rbt --show-all=htop
+    rbt --show-file=htop
 
 ## Postinstallation steps
 
@@ -3499,7 +3453,7 @@ Have a look at the file called **vte.yml** for a complete example.
 
 You can put <b>/usr/bin/</b> at the beginning of $PATH, via:
 
-    ry --traditional-path
+    rbt --traditional-path
 
 This may be useful if you ever run into some PATH-related
 problems, such as when you mix different paths. I have had
@@ -3529,7 +3483,7 @@ If you want to find out whether a program, such as "pacman",
 requires the use of autogen, you can use this query to find
 out on the commandline:
 
-    ry pacman -use-autogen?
+    rbt pacman -use-autogen?
 
 The result may be output like this:
 
@@ -3539,14 +3493,14 @@ The result may be output like this:
 
 You can e. g. select a local version via:
 
-    ry python --2
+    rbt python --2
 
 This will only work if you have a python version available locally
 in the right directory, starting with the version number **2**. 
 
 You can also use specific versions, such as in this way:
 
-    ry caja 1.21.4 --trad
+    rbt caja 1.21.4 --trad
 
 This latter example would require a tarball archive, a file, such
 as **caja-1.21.4.tar.xz**, to exist in the main directory
@@ -3627,8 +3581,8 @@ spelling.
 
 Examples:
 
-    ry htop --disable-colours
-    ry htop --disable-colors
+    rbt htop --disable-colours
+    rbt htop --disable-colors
 
 This would try to compile htop while disabling colour support for
 the current compilation-run.
@@ -3638,7 +3592,7 @@ More shortcuts exist as well, such as "nocolours" and so forth.
 If you want to **permanently disable the colours**, use a commandline
 variant such as the following:
 
-    ry --permanently-disable-colours
+    rbt --permanently-disable-colours
 
 This will modify the file '<b>use_colours.yml</b>' in the 
 **yaml/** subdirectory of the RBT project, which is the file
@@ -3661,45 +3615,18 @@ which build system is to be used; and you can also instruct
 For example, if you wish to specifically use **configure**, then
 you can do this:
 
-    ry htop --use-this-build-system=configure
+    rbt htop --use-this-build-system=configure
 
 Or, if you want to use an even shorter variant, the following example
 is equivalent to the one issued above:
 
-    ry htop --use-configure
+    rbt htop --use-configure
 
 Similarly, for **cmake** or **meson**, you could use any of the
 following variants:
 
-    ry htop --use-this-build-system=cmake
-    ry htop --use-this-build-system=meson
-
-## Configure options saved
-
-The **configure options** that were used in order to compile a particular
-program at hand, will be stored in the file called
-<b>configure_command_database.yml</b>, which can typically be found
-at a location such as:
-
-    /Depot/Temp/rbt/configure_command_database.yml
-
-The entries in this yaml file may look like this:
-
-  minuet: cmake -DCMAKE_INSTALL_PREFIX=/usr/ /Depot/Temp/rbt/minuet-18.12.3/ 2>&1
-
-So the format is - first comes **the name of the program**; followed by the
-particular command that was invoked.
-
-Note that this will **only** be stored in that .yml file if no problem was
-encountered during compilation - thus, assumingly, would mean that the
-compilation was successful or at the least continued without major
-problems/errors encountered.
-
-The primary reason as to why this functionality was added was so that the
-user can quickly look at that .yml file and see which configure option was
-used to compile a program. This may be useful at some later time when you
-wish to find out what went wrong (if something went wrong) or perhaps
-if you can not access the xorg-server but need to re-compile something.
+    rbt htop --use-this-build-system=cmake
+    rbt htop --use-this-build-system=meson
 
 ## LXQt
 
@@ -3710,15 +3637,15 @@ computer system.
 You can compile individual **LXQt components**, such as in this 
 convenient way, through **rbt**:
 
-    ry --lxqt1 # ← This refers to "libqtxdg"
-    ry --lxqt2 # ← This refers to "lxqtbuildtools"
-    ry --lxqt3 # ← This refers to "libsysstat"
-    ry --lxqt4 # ← This refers to "liblxqt"
-    ry --lxqt5 # ← This refers to "lxqtabout"
-    ry --lxqt6 # ← This refers to "lxqtadmin"
-    ry --lxqt7 # ← This refers to "lxqtconfig"
-    ry --lxqt8 # ← This refers to "lxqtglobalkeys"
-    ry --lxqt9 # ← This refers to "lxqtl10n"
+    rbt --lxqt1 # ← This refers to "libqtxdg"
+    rbt --lxqt2 # ← This refers to "lxqtbuildtools"
+    rbt --lxqt3 # ← This refers to "libsysstat"
+    rbt --lxqt4 # ← This refers to "liblxqt"
+    rbt --lxqt5 # ← This refers to "lxqtabout"
+    rbt --lxqt6 # ← This refers to "lxqtadmin"
+    rbt --lxqt7 # ← This refers to "lxqtconfig"
+    rbt --lxqt8 # ← This refers to "lxqtglobalkeys"
+    rbt --lxqt9 # ← This refers to "lxqtl10n"
 
 and so forth.
 
@@ -3729,10 +3656,10 @@ purely due to convenience.
 Examples for the long names corresponding to **--lxqt1**, **--lxqt2**,
 **--lxqt3**, **--lxqt4**, would be:
 
-    ry libqtxdg        # lxqt1
-    ry lxqtbuildtools  # lxqt2
-    ry libsysstat      # lxqt3
-    ry liblxqt         # lxqt4
+    rbt libqtxdg        # lxqt1
+    rbt lxqtbuildtools  # lxqt2
+    rbt libsysstat      # lxqt3
+    rbt liblxqt         # lxqt4
 
 (See the content of the file called **chained_programs.yml** for
 the complete listing of all LXQt components.)
@@ -3741,7 +3668,7 @@ If you wish to compile all LXQt components, in the order specified
 by the file **chained_programs.yml**, then you can use this
 commandline instruction:
 
-    ry --compile-lxqt
+    rbt --compile-lxqt
 
 You can also **manually update lxqt** via the following **top-level API**
 from within ruby:
@@ -3764,10 +3691,10 @@ to install, followed by hitting the **TAB** key.
 
 Let us next look at how **generate** these (**tab**) **completions**:
 
-    ry --generate-completions
-    ry --generate-completions
-    ry --completion
-    ry --completion
+    rbt --generate-completions
+    rbt --generate-completions
+    rbt --completion
+    rbt --completion
 
 The code for this functionality resides in these two files:
 
@@ -3778,7 +3705,7 @@ Now - after you have sourced this file into your shell, e. g.
 via **source /path/to/the/file.sh**, you should be able to
 use the tab-completions, like:
 
-    ry gnomede**TAB**
+    rbt gnomede**TAB**
 
 **TAB** in the context above means **to press the tab key** on
 the keyboard.
@@ -3792,20 +3719,7 @@ may simplify making use of it. I source that .sh file in my
 If you want to find out where that .sh file exists on your system,
 try this commandline invocation:
 
-    ry --shell-completion?
-
-## Installing the registered python addons
-
-The RBT project has some python add-ons registered. These can
-be installed via either:
-
-    ry --enable-python-addons
-    ry --python-addons
-
-You will most likely not need this, since this is catered to my
-own use case (since I have to batch-install things on a new
-computer, for example). But the option exists nonetheless, since
-as of March 2019.
+    rbt --shell-completion?
 
 ## Generate a .html file for several programs
 
@@ -3908,7 +3822,7 @@ file, called **use_porg.yml**.
 To query from the commandline whether porg is available on the
 given computer system, try:
 
-    ry --is-porg-available?
+    rbt --is-porg-available?
 
 ## Some options for the individual cookbook files explained
 
@@ -3928,18 +3842,6 @@ a configure step would fail. (Note that there may be other
 ways to do the same, but for the time being, <b>run_configure</b>
 seems simple and effective.)
 
-## Changing the prefix in any given Makefile
-
-Since as of 03.05.2019 (3rd May of 2019) it is now possible to change
-the prefix in a given **Makefile**, via class **RBT::ChangePrefix**.
-
-This class can modify the PREFIX variable in that Makefile. It was added
-so that we can change the PREFIX target of any Makefile on the fly.
-
-Currently it does not have a lot of configurable options but this may
-change in the future. For the time being, the first argument should
-be **the path to the Makefile** that should be modified.
-
 ## Xorg
 
 The Xorg-Server is the main implementation for the graphical Linux
@@ -3952,7 +3854,7 @@ all of the **xorg-proto** programs.
 
 To invoke that functionality, do:
 
-    ry --compile-all-protos
+    rbt --compile-all-protos
 
 Do note that since some time, at about the year 2018 or so, the
 individual protos have been bundled into the project called
@@ -3961,43 +3863,43 @@ individual protos have been bundled into the project called
 If you want to display all <b>xorg-related entries on the
 commandline</b>, do:
 
-    ry --tags=xorg
+    rbt --tags=xorg
 
 You can also **compile** the xorg components in an **ordered fashion**,
 by making use of numbers.
 
 Examples:
 
-    ry xorg1
-    ry xorg2
-    ry xorg3
-    ry xorg4
+    rbt xorg1
+    rbt xorg2
+    rbt xorg3
+    rbt xorg4
 
 And so forth.
 
 To batch compile most of these components, try:
 
-    ry xorg1..200
+    rbt xorg1..200
 
 If you wish to compile post-xorg-server components, that is
 components that ought to be installed after **xorg-server*
 has been compiled/installed, then the following commandline
 may be used:
 
-    ry --compile-xorg-server-post
-    ry --post-xorg-server
+    rbt --compile-xorg-server-post
+    rbt --post-xorg-server
 
 If you wish to only compile some of the addons, in particular
 input-addons related to mouse, keyboard, and a few more
 entries, then you can issue the following command:
 
-    ry --compile-mouse-and-keyboard
+    rbt --compile-mouse-and-keyboard
 
 If you wish to compile all xorg-libraries, also called as
 the **xorg-base**, you can issue any of the following commands:
 
-    ry --compile-xorg-libraries
-    ry --compile-xorg-base
+    rbt --compile-xorg-libraries
+    rbt --compile-xorg-base
       
 ## Gentoo and ebuilds
 
@@ -4009,10 +3911,10 @@ someone else has to do the testing.
 
 You can give the current implementation a try though, via:
 
-    ry ruby --create_ebuild_recipe
-    ry php --create_ebuild_recipe
-    ry perl --create_ebuild_recipe
-    ry python --create_ebuild_recipe
+    rbt ruby --create_ebuild_recipe
+    rbt php --create_ebuild_recipe
+    rbt perl --create_ebuild_recipe
+    rbt python --create_ebuild_recipe
 
 And see which parts aren't working well yet.
 
@@ -4064,8 +3966,8 @@ installed into that directory.
 If you wish to permanently set to another directory you can use this
 commandline flag:
 
-    ry --permanently_set_programs_dir=/pkg
-    ry --use-this-as-programs-dir=/pkg
+    rbt --permanently_set_programs_dir=/pkg
+    rbt --use-this-as-programs-dir=/pkg
 
 ## pre_configure_steps
 
@@ -4170,15 +4072,15 @@ that.
 
 ## Some commandline options explained
 
-If you do not want to pick up the configure options from a
-specific .yml file, you can pass in the option
+If you do not want to pick up the **configure options** from
+a specific .yml file, you can pass in the option
 **--dont-use-configure-options** to avoid doing so.
 
 Examples:
 
-    ry htop --dont-use-configure-options
-    ry glib --user-home-prefix --use-meson --no-configure-options
-    ry ruby --do-not-use-any-configure-options
+    rbt htop --dont-use-configure-options
+    rbt glib --user-home-prefix --use-meson --no-configure-options
+    rbt ruby --do-not-use-any-configure-options
 
 This allows you to just use the "barebones" compilation mode;
 may be helpful if you encounter some errors due to the 
@@ -4189,7 +4091,7 @@ configure options used.
 If you want to, for example, show the last 8 compiled programs,
 then the following commandline may be useful:
 
-    ry --last-compiled=8
+    rbt --last-compiled=8
 
 Note that you first have to have compiled some programs, as
 otherwise nothing, or less than 8 programs, would be shown.
@@ -4197,17 +4099,17 @@ otherwise nothing, or less than 8 programs, would be shown.
 As of October 2019, another way can also be used, if you wish
 to show all last compiled programs:
 
-    ry --last-compilations?
+    rbt --last-compilations?
 
 To show only the last compiled program, try this:
 
-    ry --last-compiled-program?
+    rbt --last-compiled-program?
 
 If you want to find out which were the last 20 programs that were
 compiled, then you can use this commandline option as shown
 above:
 
-    ry --last-compiled=20
+    rbt --last-compiled=20
 
 ## Speeding up the compilation
 
@@ -4232,7 +4134,7 @@ this way, on <b>Linux</b>:
 You can also obtain this from RBT itself, on the commandline,
 via:
 
-    ry --n-processors?
+    rbt --n-processors?
 
 Passing the option **-j4** to make means to "**spawn off 4 parallel
 compiling processes**". There is actually not a limit for the
@@ -4249,15 +4151,15 @@ If you wish to append the default value to make -j, which is the
 number of processors that the local computer has, then do
 this, for example:
 
-    ry flac ntrad --speed-up-the-compilation
-    ry ruby --ntrad --speed-up-the-compilation
+    rbt flac ntrad --speed-up-the-compilation
+    rbt ruby --ntrad --speed-up-the-compilation
 
 The important option here is <b>--speed-up-the-compilation</b>.
 
 Note that you can also directly pass this -j option to rbt,
 such as exemplified through the following **usage example**:
 
-    ry lame -j5
+    rbt lame -j5
 
 This is the same as doing "**make -j5**", by the way, during
 the <b>make step</b>.
@@ -4280,8 +4182,8 @@ This can also be disabled for the individual run, via:
 
 More complete example how to disable this from the commandline:
 
-    ry lame --do-not-use-maximum-speed
-    ry xvidcore --ntrad --donot-use-maximum-speed
+    rbt lame --do-not-use-maximum-speed
+    rbt xvidcore --ntrad --donot-use-maximum-speed
 
 It seemed important to provide this option on the commandline because
 the end user may **not** want to use maximum speed for compilation,
@@ -4323,10 +4225,10 @@ it up and running quickly, anyway.
 
 Invocation examples:
 
-    ry --compile-libstdc
-    ry --compile-libstdc++
-    ry --install-libstdc
-    ry --install-libstdc++
+    rbt --compile-libstdc
+    rbt --compile-libstdc++
+    rbt --install-libstdc
+    rbt --install-libstdc++
 
 # class RBT::ShowDescriptionAndExtraInformation
 
@@ -4378,18 +4280,18 @@ the commandline flag called **--show-flexbox-only**.
 
 Usage examples for this:
 
-    ry ruby --show-flexbox-only
-    ry python --show-flexbox-only
-    ry php --show-flexbox-only
+    rbt ruby --show-flexbox-only
+    rbt python --show-flexbox-only
+    rbt php --show-flexbox-only
 
 If you do not wish to see this flexbox (as infobox) during compilation,
 you can also **disable** it for the current compilation/installation
 run, via a commandline flag such as **--no-flexbox**:
 
-    ry ruby --no-flexbox
-    ry python --no-flexbox
-    ry php --no-flexbox
-    ry sed --no-flexbox
+    rbt ruby --no-flexbox
+    rbt python --no-flexbox
+    rbt php --no-flexbox
+    rbt sed --no-flexbox
 
 You can also use the flexbox directly, through **bin/flexbox**
 if you have the AsciiParadise installed, such as in:
@@ -4442,7 +4344,7 @@ assumptions for now.
 If you need to show all statically compiled programs on the given
 computer system then the following may be of help:
 
-    ry --static-overview?
+    rbt --static-overview?
 
 Note that the checks used here are not perfect, so expect some
 false positives. But for a quick overview this should do fine.
@@ -4468,8 +4370,8 @@ if the error reported is not a real error. Thus, the user
 needs to have a way to overrule this behaviour, which can
 be done by the following commandline flag:
 
-    ry --dont-stop-on-errors
-    ry --ignore-errors
+    rbt --dont-stop-on-errors
+    rbt --ignore-errors
 
 This would instruct **RBT::Compile** to **not** stop on
 errors and instead (try to) continue.
@@ -4486,11 +4388,11 @@ also have to occur.
 You can pass in which particular pre-install action should be
 done, via:
 
-    ry htop --preinstall="sh bootstrap"
-    ry htop --prerun="sh bootstrap"
+    rbt htop --preinstall="sh bootstrap"
+    rbt htop --prerun="sh bootstrap"
 
-    ry htop --preinstall="sh bootstrap, clear"
-    ry htop --prerun="sh bootstrap; clear"
+    rbt htop --preinstall="sh bootstrap, clear"
+    rbt htop --prerun="sh bootstrap; clear"
 
 As can be seen above, you can separate multiple arguments via
 either ',' or ';'.
@@ -4510,50 +4412,6 @@ The classes-approach leads to somewhat more lines of code, but
 it also is easier to read, and it will properly inform the
 user as to what is done.
 
-## Configure options and passing additional configure options
-
-The content of the various .yml files may have an entry called
-**configure_options**. This is usually the entry that keeps
-track of the arguments that you may normally pass towards
-**./configure**, such as **--enable-static** or **--disable-shared**.
-
-Different build systems, such as meson, use a slightly different
-syntax, such as **-Dlibpsl=false**. Additionally, I sometimes
-want to preserve the old configure options, so that I can compile
-different versions of a given program where the build system may
-have changed. That is why I added, in December 2018, the ability
-to use specific configure options for **meson**. These are called
-**meson_configure_options**. An example for this may be the
-file **networkmanager.yml**.
-
-Some configure options can be passed to an instance of **RBT::Compile**
-as well.
-
-For example, if you wish to use --enable-shared then you can simply
-pass it, like so:
-
-    ry htop --enable-shared
-
-This will simply pass the configure option --enable-shared.
-
-In the future, more options will probably be added. Some options
-may be translated into the equivalent cmake-option, if cmake is
-used, but for the time being, this is presently (November 2018)
-not well supported. Stay tuned for later changes in this regard.
-
-Since as of **November 2019**, the configure options that were used
-to compile a program, will also be stored into the target
-file at **Resources/configure_options.md** if it was installed
-via an AppDir prefix (e. g. **/Programs/Ruby/2.6.5/** and
-similar), if the compilation was a success **and** if there was
-**at the least one** configure options - thus, empty Strings will
-not be stored.
-
-This file will only store the actual configure_options that were
-used; for the full configure-like command, see the corresponding
-file in the same directory, whose name is
-**full_configure_command.md**.
-
 ## class RBT::MapThisInputToThatRegisteredProgram
 
 class **RBT::MapThisInputToThatRegisteredProgram** was added
@@ -4615,35 +4473,35 @@ Specific examples follow next.
 First, to display an overview of the available profiles, you can issue
 any of the following commands:
 
-    ry --available-profiles
-    ry --profiles?
+    rbt --available-profiles
+    rbt --profiles?
     
 In order to use the profile for **GCC first pass**, as described in the
 **LFS project**, use a commandline switch as the following:
 
-    ry gcc --profile=gcc_lfs_pass1
+    rbt gcc --profile=gcc_lfs_pass1
 
 If you want to compile a minimal GCC, into its versioned AppDir prefix,
 then you can use the following call:
 
-    ry gcc --profile=gcc-minimal --ntrad
+    rbt gcc --profile=gcc-minimal --ntrad
 
 You can also use a slightly more explicit variant:
 
-    ry qt --use-profile=qt
-    ry qt --use-profile=qt --trad
+    rbt qt --use-profile=qt
+    rbt qt --use-profile=qt --trad
 
 For some profiles you can also use a shorter variant, such as 
 **--basic-gcc** for --profile=gcc-minimal:
 
-    ry gcc trad --basic-gcc
+    rbt gcc trad --basic-gcc
 
 In order to see individual profiles based on the program name
 at hand, such as **gcc**, you can use this sub-query search:
 
-    ry --show-this-profile=gcc
-    ry --show-these-profiles=gcc
-    ry --profiles-of?=gcc
+    rbt --show-this-profile=gcc
+    rbt --show-these-profiles=gcc
+    rbt --profiles-of?=gcc
 
 Note that in order to display such a profile, it has to exist. If
 it does not exist for the given program at hand then **RBT** will
@@ -4653,7 +4511,7 @@ notify the user about this fact.
 
 You can invoke, from the commandline, the following:
 
-    ry --validate-entries
+    rbt --validate-entries
 
 This will validate the dataset stored in the various .yml files.
 
@@ -4721,9 +4579,9 @@ directory structure through just one argument, to that class.
 You can also use this from the commandline, if you would like to
 do so, via <b>rbt</b> like in the following examples:
 
-    ry --create-program=foo-1.0
-    ry --create-program=php-7.4.3
-    ry --create-program=python-3.3.3
+    rbt --create-program=foo-1.0
+    rbt --create-program=php-7.4.3
+    rbt --create-program=python-3.3.3
 
 Do take note that CreateAppDirSkeleton may be called from some RBT scripts,
 in particular **RBT::Compile**. Some directories will not see that
@@ -4739,8 +4597,8 @@ If you wish to make use of that directory, as the input, as if you
 would have passed the above as String into RBT::CreateAppDirSkeleton.new(),
 you can use either of the following two variants:
 
-    ry --create-program
-    ry --rcp
+    rbt --create-program
+    rbt --rcp
 
 ## Compile statistics
 
@@ -4792,8 +4650,8 @@ Programs hierarchy (**/home/Programs/** on my system).
 
 To invoke this from the commandline, try either of the following:
 
-    ry --purge-incorrect-yaml-directories-in-the-programs-hierarchy
-    ry --purge-flawed-yaml-directories-in-the-programs-hierarchy
+    rbt --purge-incorrect-yaml-directories-in-the-programs-hierarchy
+    rbt --purge-flawed-yaml-directories-in-the-programs-hierarchy
 
 Do note that this class is largely unnecessary these days - it was
 created as a quick ad-hoc solution, to work around the buggy
@@ -4831,12 +4689,13 @@ as an input.
 
 Example:
 
-    ry xau.pc # ← This is equivalent to "ry libxau"
+    rbt xau.pc # ← This is equivalent to "ry libxau"
+    rbt xscrnsaver.pc --ntrad # ← This will substitute for "libxscrnsaver". You can use .pc files as input arguments.
 
 You can also compile through registered .h header files such 
 as shown in the following example:
 
-    ry  SMlib.h --ntrad
+    rbt  SMlib.h --ntrad
 
 If you wish to see a **brief introduction on the commandline**,
 issue the following command:
@@ -4862,9 +4721,9 @@ Usage examples:
 
 Complete usage example:
 
-    ry gcc --use-these-configure-options="--enable-shared --enable-bootstrap --enable-languages=c,c++,lto,objc,fortran --enable-threads=posix --enable-checking=release --enable-objc-gc --with-system-zlib --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=gcc4-compatible --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --enable-lto --disable-install-libiberty --with-gnu-ld --verbose --with-arch-directory=amd64 --disable-gtktest --disable-multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux"
+    rbt gcc --use-these-configure-options="--enable-shared --enable-bootstrap --enable-languages=c,c++,lto,objc,fortran --enable-threads=posix --enable-checking=release --enable-objc-gc --with-system-zlib --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=gcc4-compatible --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --enable-lto --disable-install-libiberty --with-gnu-ld --verbose --with-arch-directory=amd64 --disable-gtktest --disable-multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux"
 
-    ry poppler --use-these-configure-options="--enable-xpdf-headers"
+    rbt poppler --use-these-configure-options="--enable-xpdf-headers"
 
 ## File simple_appdir_configure.rb
 
@@ -4900,47 +4759,14 @@ remove empty subdirectories of programs that are installed in an
 This is not always wanted, though, so a commandline flag exists to disable
 the auto-removal of empty directories:
 
-    ry feh --ntrad --do-not-remove-empty-directories
+    rbt feh --ntrad --do-not-remove-empty-directories
 
 ## Ensuring that all relevant directories exist
 
 To ensure that all important directories exist you can invoke
 the following method to do so:
 
-    ry --ensure-all-directories-exist
-
-## Removing outdated (local) archives
-
-I tend to batch-update the RBT project quite frequently. As a result
-of this, I end up having lots of local archives, usually in the
-**.tar.xz** format. Since removing these manually is annoying, a
-class has been added on **07.01.2020**, called
-**RBT::RemoveOutdatedArchives**.
-
-This class is presently not very flexible, since I only used it
-to remove a specific set of programs.
-
-For example:
-
-    RBT::RemoveOutdatedArchives.new(:kde_plasma)
-
-This would remove all outdated archives belonging to the KDE
-Plasma stack.
-
-Another example:
-
-    RBT::RemoveOutdatedArchives.new(:kde_applications)
-
-The above would remove all outdated KDE5 applications (if all
-goes well).
-
-In the future this class may be extended, but for now this has
-to suffice.
-
-Also note that whenever this paragraph refers to KDE, it refers
-to KDE5. This may change in the future (e. g. KDE6 release
-and similar), but for now (January 2020) it is up-to-date and
-thus correct.
+    rbt --ensure-all-directories-exist
 
 ## class RBT::SymlinkThisProgram
 
@@ -4981,7 +4807,7 @@ this class should work fine, though.
 The required dependencies of a given program at hand can be compiled
 or installed, respectively, via the following means:
 
-    ry rails --install-its-dependencies
+    rbt rails --install-its-dependencies
 
 This will NOT install the program itself, though - in this case
 **rails**. It is just a quick-and-dirty way to compile 
@@ -4996,9 +4822,9 @@ such as **htop.yml** or **poppler.yml**.
 You can also batch-compile these programs, such as the instruction
 of "compile all programs that belong to the tag called game":
 
-    ry --compile-this-tag=game
-    ry --compile-this-tag=gnome
-    ry --compile-tags=pdf
+    rbt --compile-this-tag=game
+    rbt --compile-this-tag=gnome
+    rbt --compile-tags=pdf
 
 The tag that you wish to compile has to exist of course, as otherwise
 no program would be compiled. It has to be registered as part of
@@ -5047,8 +4873,8 @@ prefix.
 If you specifically do not want this, then use the commandline
 flag called **--do-not-symlink-gir-file**. Example for this:
 
-    ry upower --ntrad --do-not-symlink-gir-file
-    ry gnomedesktop --ntrad --do-not-symlink-gir-files
+    rbt upower --ntrad --do-not-symlink-gir-file
+    rbt gnomedesktop --ntrad --do-not-symlink-gir-files
 
 ## build_systems_priorities.yml
 
@@ -5082,8 +4908,8 @@ To query, on the commandline, which build system will be
 prioritized you can use any of the following configure
 switches:
 
-    ry --priorities?
-    ry --build-system-priorities?
+    rbt --priorities?
+    rbt --build-system-priorities?
 
 Internally the method **RBT.infer_build_system()** can be used
 to try to guess the build system, while also honouring the
@@ -5110,9 +4936,9 @@ Because the above is a bit inconvenient to type, the entry **flatpak_url:**
 has been added to the cookbooks part of RBT, which allows you to do
 the above, through **rbt*+, in this way:
 
-    ry --install-the-flatpak-for=firefox
-    ry --flatpak-for=firefox
-    ry --flaty=firefox
+    rbt --install-the-flatpak-for=firefox
+    rbt --flatpak-for=firefox
+    rbt --flaty=firefox
 
 Either variant will essentially just do the above "flatpak install --user URL"
 part.
@@ -5225,7 +5051,7 @@ If you wish to quickly **paste** the BLFS page of a given program onto
 the commandline, for display purpose, then you can do something
 like this:
 
-    ry php --parseblfs
+    rbt php --parseblfs
 
 Add some later point in the future (August 2019), this may even
 become its own bin/ entry - we'll see about that.
@@ -5246,7 +5072,7 @@ stage.
 
 Usage example:
 
-    ry --parse-blfs-page-for=llvm
+    rbt --parse-blfs-page-for=llvm
 
 In **December 2019** another feature was added - the ability to
 make use of the BLFS instructions directly, and run them.
@@ -5257,7 +5083,7 @@ you are working on the commandline only.
 
 Invocation example:
 
-    ry kerberos --use-blfs-instructions # Compile kerberos in the BLFS way.
+    rbt kerberos --use-blfs-instructions # Compile kerberos in the BLFS way.
 
 ## Copying archives to the current working directory
 
@@ -5491,7 +5317,7 @@ you can use this toplevel-API:
 
 You can batch-update all <b>registered rubygems</b> via:
 
-    ry --update-all-gems
+    rbt --update-all-gems
 
 Note that this presently will only work if you use the Cookbooks
 project. I am open to extend this functionality to allow other
@@ -5510,7 +5336,7 @@ If you do not want to, or can not, update all registered .gem
 entries, yet you still want to install the .gem files that are
 registered, then you can use this commandline:
 
-    ry --install-all-rubygems
+    rbt --install-all-rubygems
 
 This will install all registered .gem files, in an alphabetical
 manner. Dependencies will not be checked that way, but in
@@ -5576,14 +5402,14 @@ via:
 And from the commandline, you can invoke it via the following
 invocation:
 
-    ry --compile_strategies?
+    rbt --compile_strategies?
 
 If you would like to see a more comprehensive overview over
 the whole RBT project, and associated statistics, you can
 do so via either of the following variants:
 
-    ry --stats?
-    ry --stats?
+    rbt --stats?
+    rbt --stats?
 
 This will essentially invoke class **RBT::ShowStatistics**,
 which in turn calls the other classes. (Take note that this
@@ -5592,9 +5418,22 @@ processed.)
 
 The cookbook-submodule of the RBT project also includes some
 statistics, which can be next seen **here**, displayed (and
-stored) in the file called **rbt/doc/COOKBOOK_STATISTICS.md**:
+stored) in the file called **rbt/doc/cookbook_statistics.md**:
+
+In **April 2021**, the output of class RBT::ShowHowManyFilesAreTracked was
+as follows:
+
+    There are  3725 programs registered in total in the RBT project.
+    There are  5500 binaries registered in the RBT project.
+    There are 24031 .h header files registered in the RBT project.
+    There are 11620 .so / .a library files registered in the RBT project.
+    There are   120 .gir files registered in the RBT project.
+    There are    11 .m4 files registered in the RBT project.
 
-INCLUDE_THIS_FILE doc/COOKBOOK_STATISTICS.md
+This should give you some overview as to how many files are 
+tracked so far, within the RBT project as-is.
+
+INCLUDE_THIS_FILE doc/cookbook_statistics.md
 
 ## Expanding the cookbook dataset within the RBT project
 
@@ -5637,8 +5476,8 @@ the long run.
 In order to do so, you can invoke the rbt project via any of the
 following **commandline flag**:
 
-    ry --expand
-    ry --expand-dataset 
+    rbt --expand
+    rbt --expand-dataset 
 
 You normally only have to do this **once**, but it is a purely
 optional step. It is recommended to do so, though.
@@ -5685,7 +5524,7 @@ class directly. These .rb files will reside in the subdirectory
 Alternatively, you can invoke them directly from the commandline
 like so:
 
-    ry --update-kde-plasma
+    rbt --update-kde-plasma
 
 This will download all of the KDE5 plasma components (unless they
 are already available locally).
@@ -5693,12 +5532,12 @@ are already available locally).
 If you wish to download the **KDE5 applications**, then you can
 try this command:
 
-    ry --update-kde-applications
+    rbt --update-kde-applications
 
 **Aliases** exist to the above:
 
-    ry --kde-apps
-    ry --compile-kde-apps
+    rbt --kde-apps
+    rbt --compile-kde-apps
 
 In general, the **rbt project** attempts to allow aliases, for
 sake of convenience. The "official" entry points are usually the
@@ -5710,28 +5549,28 @@ commandline).
 
 To update the **KDE5 Frameworks**, do:
 
-    ry --update-kde-framework
+    rbt --update-kde-framework
 
 To update the **KDE5 porting aids**, do:
 
-    ry --update-kde-porting-aids
+    rbt --update-kde-porting-aids
 
 And to then compile them, do:
 
-    ry --compile-porting-aids
+    rbt --compile-porting-aids
 
 Note that you could also use '_' **tokens** in the above invocation
 examples, or omit these, so the following would work just as well:
 
-    ry --update_kde_porting_aids
-    ry --updatekdeportingaids
-    ry --compile_porting_aids
-    ry --compile-porting-aids
+    rbt --update_kde_porting_aids
+    rbt --updatekdeportingaids
+    rbt --compile_porting_aids
+    rbt --compile-porting-aids
 
 You can also query the KDE "status", that is, which variant is
 currently the most recent one. Use something like this:
 
-    ry --kde-status
+    rbt --kde-status
 
 The output of the above command, on the commandline, would be something
 like this:
@@ -5768,9 +5607,9 @@ You can also use a **number** to **compile a particular KDE component**.
 
 For example:
 
-    ry --kde1
-    ry --kde2
-    ry --kde3
+    rbt --kde1
+    rbt --kde2
+    rbt --kde3
 
 Will compile these registered kde components. The reason as to why
 this functionality exists is that it makes batch-compiling the KDE
@@ -5780,14 +5619,14 @@ is quite bad, so using numbers is so much easier).
 
 You can drop the **--** too, of course:
 
-    ry kde1
-    ry kde2
-    ry kde3
-    ry --kde4 # Using leading -- also works.
+    rbt kde1
+    rbt kde2
+    rbt kde3
+    rbt --kde4 # Using leading -- also works.
 
 You can chain these via a range-like syntax:
 
-    ry kde1..100
+    rbt kde1..100
 
 This would compile the first 100 KDE components (if all goes well
 and no errors have occurred).
@@ -5795,7 +5634,7 @@ and no errors have occurred).
 You can also be more verbose, if you'd like to. The following
 demonstrates this:
 
-    ry --kde1..kde250
+    rbt --kde1..kde250
 
 The linear order of these numbers can be seen in the file
 **rbt/yaml/chained_programs.yml**, under the respective KDE component
@@ -5804,27 +5643,27 @@ The linear order of these numbers can be seen in the file
 If you wish to compile all of the KDE5 plasma components, you can
 use either one of the following variants:
 
-    ry --compile-all-kde5-plasma-components
-    ry --compile-plasma
-    ry --compile-all-of-plasma
+    rbt --compile-all-kde5-plasma-components
+    rbt --compile-plasma
+    rbt --compile-all-of-plasma
 
 This is a convenience-shortcut. Of course the option with --batch=
 also works.
 
 To update all kde-applications you could do the following:
 
-    ry --update-kde-apps
+    rbt --update-kde-apps
 
 To compile all of KDE, try this:
 
-    ry --compile-all-of-kde
+    rbt --compile-all-of-kde
 
 If you wish to compile only the components up to (and including)
 the KDE konsole, which I often do, then the following invocation
 should achieve this:
 
-    ry --compile-all-up-until-konsole
-    ry --compile-towards-konsole # ← This is equivalent to the above ^^^.
+    rbt --compile-all-up-until-konsole
+    rbt --compile-towards-konsole # ← This is equivalent to the above ^^^.
 
 ## Aliases for program names
 
@@ -5843,8 +5682,8 @@ happening.
 
 Invoke it like so:
 
-    ry sdlttf --do-not-use-cookbook-aliases
-    ry sdlttf --do-not-use-cookbook-alias  
+    rbt sdlttf --do-not-use-cookbook-aliases
+    rbt sdlttf --do-not-use-cookbook-alias  
 
 This will specifically **disable** making use of <b>cookbook
 aliases</b>. (That functionality only works if the Cookbooks
@@ -5862,7 +5701,7 @@ If you would like to download an archive from a **remote URL** into a specific
 (local) directory, you can use an **API** such as this here, from the
 commandline:
 
-    ry htop --download-into-this-directory=/opt/bla/
+    rbt htop --download-into-this-directory=/opt/bla/
 
 The **first argument** is the registered program that ought to be used; in
 this case the program called **htop**. The second argument specifies the local
@@ -5870,8 +5709,16 @@ directory to be used, in this case **/opt/bla/**. Obviously you could also
 download first, and then **mv** the file anyway, but sometimes you may want
 to do it in one go.
 
+Note that you can simplify the above if you wish to download into the
+current working directory. If this is the case, you can use
+this variant instead:
+
+    rbt htop --downloadhere
+
+This will download the htop archive into the current working directory.
+
 If you wish to quickly download e. g. htop or another program, you can
-also use the following simpler toplevel API (from within ruby):
+also use the following simpler **toplevel API** (from within ruby):
 
     RBT.download :htop
 
@@ -5880,35 +5727,37 @@ the following API with the full URL instead:
 
     RBT.download 'http://hisham.hm/htop/releases/2.2.0/htop-2.2.0.tar.gz'
 
-It thus is simply **a convenience feature**. Obviously
-"wget http://hisham.hm/htop/releases/2.2.0/htop-2.2.0.tar.gz" is
-simpler, but since RBT makes use of ruby, functionality such as 
-this has to be included.
+It thus is simply **a convenience feature** and works really well
+in **irb*. Obviously "wget http://hisham.hm/htop/releases/2.2.0/htop-2.2.0.tar.gz"
+may be simpler on Linux-based systems, but since RBT makes use
+of ruby, functionality such as this has to be included. We want
+to remain flexible and succint whenever that is meaningfully
+possible.
 
 You can also use the current directory as input, e. g. if you
 would first create the directory htop, then cd into it, and
 then invoke that method:
 
-    RBT.download :pwd
+    RBT.download :pwd # the symbol :pwd will be treated as referring to the current working directory
 
 This may save a little bit of typing.
 
 The functionality can also be used from the **commandline**, through
 the **bin/rbt** script, such as in the following examples:
 
-    ry --download htop
-    ry --download ruby
-    ry --download python
-    ry --download php
+    rbt --download htop
+    rbt --download ruby
+    rbt --download python
+    rbt --download php
 
 This would download **htop**, or **ruby**, or **python**, respectively,
 into the **current working directory**.
 
 Note that the following syntax works as well:
 
-    ry --download=htop
-    ry --download=ruby
-    ry --download=python
+    rbt --download=htop
+    rbt --download=ruby
+    rbt --download=python
 
 Use whatever you prefer here, ' ' or '=' work just fine. I recommend
 to use the '=' all the time since the code checking this is a bit
@@ -5930,7 +5779,7 @@ Or put an alias to this to make this even shorter.
 If you wish to find out which programs can be downloaded that
 way, you could try to issue this command:
 
-    ry --show-downloadable-programs
+    rbt --show-downloadable-programs
 
 This will display all the names of the registered programs,
 more than 3500 (so it is quite a long output; you may want
@@ -5942,8 +5791,8 @@ expects source archives to reside at.
 
 Examples:
 
-    ry --download-into-proper-directory htop
-    ry --download-proper ruby # ← This variant is significantly shorter
+    rbt --download-into-proper-directory htop
+    rbt --download-proper ruby # ← This variant is significantly shorter
 
 On my home system, this would download
 http://hisham.hm/htop/releases/2.2.0/htop-2.2.0.tar.gz into
@@ -5957,9 +5806,9 @@ download different versions of a given program. As an example, let's
 say that we wish to download **glibc version 2.28**. You could
 use this commandline way in order to achieve this:
 
-    ry --download glibc-2.28
-    ry --download glibc-2.27
-    ry --download glibc-2.26
+    rbt --download glibc-2.28
+    rbt --download glibc-2.27
+    rbt --download glibc-2.26
     # and so forth
 
 This has a few constraints, though. Firstly, the remote file
@@ -6001,7 +5850,7 @@ longer name, such as **xorg-server**.
 
 You could compile it via:
 
-    ry xorgser
+    rbt xorgser
 
 That is more convenient, isn't it?
 
@@ -6049,14 +5898,14 @@ use of abbreviations.
 You can quickly repackage archives, such as **foobar-1.0.tar.gz**
 into **foobar-1.0.tar.xz**, by issuing this command:
 
-    ry --repackage=foobar-1.0.tar.gz
+    rbt --repackage=foobar-1.0.tar.gz
 
 To quickly create an archive from a compiled and installed
 AppDir, try something like this:
 
-    ry --package-this-app-dir=htop
-    ry --package-this-appdir=htop
-    ry --package-appdir=htop
+    rbt --package-this-app-dir=htop
+    rbt --package-this-appdir=htop
+    rbt --package-appdir=htop
 
 
 ## Installing the Linux Kernel Header files and/or extracting the Linux Kernel archive
@@ -6066,8 +5915,8 @@ copied to the **/usr/include/** target. I wanted this on a
 versioned AppDir layout as well, so the following commands
 were added: 
 
-    ry --install-kernel-headers
-    ry --install-linux-headers
+    rbt --install-kernel-headers
+    rbt --install-linux-headers
 
 This will essentially copy the important .h files from the linux
 kernel to the correct target AppDir location, under the corresponding
@@ -6078,7 +5927,7 @@ If you merely wish to extract the Linux Kernel archive into the
 corresponding target directory specified in the file **linux.yml**
 then you can do the following:
 
-    ry --extract-linux
+    rbt --extract-linux
 
 This is simply a convenience feature, not an important one; I wanted
 to alias **extract_linux** in bash to simply extract the current
@@ -6089,7 +5938,7 @@ e. g. at **/home/name/**.
 
 To do this, use:
 
-    ry --install-kernel-headers-into-the-home-dir
+    rbt --install-kernel-headers-into-the-home-dir
 
 ## Optimizations for compilation
 
@@ -6098,8 +5947,8 @@ This subsection will be expanded in the future.
 If you wish to compile via -O3 optimization, you can
 pass it in:
 
-    ry gnomedesktop --O3
-    ry gnomedesktop --speedy
+    rbt gnomedesktop --O3
+    rbt gnomedesktop --speedy
 
 This may lead to faster program execution, at the expense of 
 slightly larger program size - say +20% or so increase in
@@ -6115,7 +5964,7 @@ If you, like me, get tired of installing the various xorg-related
 **xcb components** then the following command should be of help
 here:
 
-    ry --compile-xcb-components
+    rbt --compile-xcb-components
 
 This will install the xcb-components in the correct order
 (actually it will compile the xcb-components).
@@ -6130,12 +5979,12 @@ Aliases exist for this:
 
 In order to **compile perl**, you could simply issue the following command:
 
-    ry perl
+    rbt perl
 
 If you wish to install the various registered perl-addons, you can
 try to use the following command:
 
-    ry --compile-perl-addons
+    rbt --compile-perl-addons
 
 (Unfortunately there is some bug, where the installation stops after
 the first installed perl program. I will have to investigate this at
@@ -6199,11 +6048,11 @@ If you wish to use /usr/lib64/ as the libdir target for
 the current invocation run, you can use **--libdir64**
 as in:
 
-    ry libgpgerror --libdir64
+    rbt libgpgerror --libdir64
 
 This is essentially equal to:
 
-    ry libgpgerror --libdir=/usr/lib64
+    rbt libgpgerror --libdir=/usr/lib64
 
 So we just save a bit of typing work. Note that --dir64
 also works, as slightly shorter variant.
@@ -6226,17 +6075,17 @@ If you wish to overrule this on the commandline and specifically
 **disable** static compilation, you can use a commandline 
 instructions such as:
 
-    ry htop --do-not-build-statically
+    rbt htop --do-not-build-statically
 
 Note that as of **December 2018** you can also combine
 --enable-shared --disable-static in one variant via:
 
-    ry libxmu --shared-no-static ntrad
+    rbt libxmu --shared-no-static ntrad
 
 To determine whether a program can be compiled statically, you can
 issue a command such as the following:
 
-    ry tar --can-be-compiled-statically?
+    rbt tar --can-be-compiled-statically?
 
 Do note that this requires a manual registration in the corresponding
 yaml file; by default this will return false (aka no).
@@ -6244,7 +6093,7 @@ yaml file; by default this will return false (aka no).
 Since as of July 2020 you can also determine which programs can
 be compiled statically in general, via:
 
-    ry --which-programs-can-be-compiled-statically?
+    rbt --which-programs-can-be-compiled-statically?
 
 ## Disable adding the shell script error line
 
@@ -6263,10 +6112,10 @@ You can generate standalone .sh (shell scripts).
 
 Examples:
 
-    ry sed        --generate_shellscript
-    ry python     --standalone
-    ry gnunetgtk  --create_shellscript
-    ry wxwidget   --shellscript
+    rbt sed        --generate_shellscript
+    rbt python     --standalone
+    rbt gnunetgtk  --create_shellscript
+    rbt wxwidget   --shellscript
 
 This will generate .sh files that are, in theory,
 usable to just compile a source archive via a
@@ -6307,8 +6156,8 @@ scripts via a local file.
 
 Consider these two invocation examples:
 
-    ry gcc --use-instructions-from-this-file=/Depot/foobar.md
-    ry php --trad --use-this-file=/Depot/j/foo.md
+    rbt gcc --use-instructions-from-this-file=/Depot/foobar.md
+    rbt php --trad --use-this-file=/Depot/j/foo.md
 
 These instructions would read in the dataset from these
 two files, and treat them as the main configure-options.
@@ -6352,9 +6201,9 @@ way.
 If you want to extract into the **home directory** instead, then
 you can use any of the following commands to do so permanently:
 
-    ry --permanently-extract-to-home
-    ry --permanently-extract-to-home-dir
-    ry --extract-to-home
+    rbt --permanently-extract-to-home
+    rbt --permanently-extract-to-home-dir
+    rbt --extract-to-home
 
 You can also specify a specific target directory that is used
 for the extraction step of a compilation that you are about
@@ -6362,7 +6211,7 @@ to start.
 
 Consider the following example:
 
-    ry htop ntrad --use-this-temp-dir=/opt/foobar_create_it 
+    rbt htop ntrad --use-this-temp-dir=/opt/foobar_create_it 
 
 This would use the directory **/opt/foobar_create_it** for
 extracting the source archive.
@@ -6387,7 +6236,7 @@ You can also quickly extract any local archive via this
 The latter method can also be used on the commandline, through
 **bin/rbt** via:
 
-    ry --extract htop
+    rbt --extract htop
 
 This will first **download htop** and then extract it, in the
 **current working directory** (**cwd**).
@@ -6395,7 +6244,7 @@ This will first **download htop** and then extract it, in the
 You can also quickly extract a locally existing archive,
 such as **bison-3.2.4.tar.xz**.
 
-    ry --extract-this=bison-3.2.4.tar.xz
+    rbt --extract-this=bison-3.2.4.tar.xz
 
 Another functionality is that you can change the directory as to
 where source archives will be extracted to, permanently, from
@@ -6406,15 +6255,15 @@ clean than /tmp/ but your mileage may vary.
 
 Examples:
 
-    ry --permanently-set-temp-dir-to=/user/bioinf4/Temp/
-    ry --permanently-set-temp-dir=/user/bioinf4/Temp/
-    ry --permanently_extract_to=pwd
-    ry --permanently_extract_to=/Depot
-    ry --permanently_extract_to=/tmp
-    ry --permanently-set-temp-dir=/user/bioinf4/Temp/
-    ry --permanently-set-temp-dir-to=/user/bioinf4/Temp/
-    ry --use-this-temp-dir=/Depot/
-    ry --use-temp=/Depot
+    rbt --permanently-set-temp-dir-to=/user/bioinf4/Temp/
+    rbt --permanently-set-temp-dir=/user/bioinf4/Temp/
+    rbt --permanently_extract_to=pwd
+    rbt --permanently_extract_to=/Depot
+    rbt --permanently_extract_to=/tmp
+    rbt --permanently-set-temp-dir=/user/bioinf4/Temp/
+    rbt --permanently-set-temp-dir-to=/user/bioinf4/Temp/
+    rbt --use-this-temp-dir=/Depot/
+    rbt --use-temp=/Depot
 
 These are all equivalent.
 
@@ -6422,7 +6271,7 @@ If you wish to extract to, for example, the target location
 **/opt/test** just for the current run, then the following
 command should suffice:
 
-    ry htop --extract-to=/opt/test
+    rbt htop --extract-to=/opt/test
 
 Sometimes you may not want to even think about a specific
 name and just wish to use any random name for a directory.
@@ -6430,10 +6279,10 @@ name and just wish to use any random name for a directory.
 In order to do so, you can use any of the following 
 ways to invoke rbt:
 
-    ry php --random-temp-dir
-    ry php --random-dir
-    ry php --random-temp
-    ry php --rdir
+    rbt php --random-temp-dir
+    rbt php --random-dir
+    rbt php --random-temp
+    rbt php --rdir
 
 This will use a temp-directory such as **/home/temp/rbt/foeghe/**.
 
@@ -6446,7 +6295,7 @@ For example, say you cd to /tmp:
 
 Next, you want to extract **htop**:
 
-    ry --extract htop
+    rbt --extract htop
 
 This should work fine if you have htop downloaded (**ry htop --download**
 should work for this as well).
@@ -6465,7 +6314,7 @@ that something has gone awry.
 
 To compile busybox, try this:
 
-    ry busybox
+    rbt busybox
 
 Make sure to compile busybox **statically**. That way you become less
 dependent on .so files being available, in the event that you somehow
@@ -6487,7 +6336,7 @@ rest is fine either way for me.
 For a static compilation of busybox, this should work fine by
 default:
 
-    ry busybox ntrad
+    rbt busybox ntrad
 
 At a later time more flexibility may be added here, but for the
 time being (November 2019) this has to suffice.
@@ -6525,11 +6374,11 @@ I am not quite sure where this .h file typically resides.
 Archlinux uses **pacman** as package manager. Installing pacman
 is quite simple:
 
-    ry pacman trad
+    rbt pacman trad
 
 You may need **libtar** too:
 
-    ry libtar trad
+    rbt libtar trad
 
 What to do next afterwards?
 
@@ -6587,11 +6436,11 @@ to have this - for now, the default colour "profile" has to suffice.
 If you wish to **permanently disable the colours** for the RBT
 project, then you may use the following command:
 
-    ry --permanently-disable-colours
+    rbt --permanently-disable-colours
 
 And to permanently enable the colours again, issue:
 
-    ry --permanently-enable-colours
+    rbt --permanently-enable-colours
 
 Note that there are also a few classes that can handle colours
 or colourizing. In particular, class **ColourizeParser** will
@@ -6616,7 +6465,7 @@ flag exists to overrule this.
 
 Invocation example:
 
-    ry glade --trad --use-simple-system
+    rbt glade --trad --use-simple-system
 
 This would just use system() instead, which is not as 
 advanced, but simpler. (Won't use as many colours
@@ -6638,70 +6487,70 @@ chroot?
 I will try to list the options here, as I use this on
 my system (or a new system):
 
-    ry make --static --chroot
-    ry bash --static --chroot # <- This may already suffice.
-    ry mpfr --chroot
-    ry gmp --chroot
-    ry mpc --chroot
-    ry sed --static --chroot
-    ry grep --static --chroot
-    ry coreutils --static --chroot
-    ry ruby --dontuseconfigureoptions --chroot
-    ry python --chroot
-    ry gawk --chroot --static
-    ry nano --static --chroot
+    rbt make --static --chroot
+    rbt bash --static --chroot # <- This may already suffice.
+    rbt mpfr --chroot
+    rbt gmp --chroot
+    rbt mpc --chroot
+    rbt sed --static --chroot
+    rbt grep --static --chroot
+    rbt coreutils --static --chroot
+    rbt ruby --dontuseconfigureoptions --chroot
+    rbt python --chroot
+    rbt gawk --chroot --static
+    rbt nano --static --chroot
     # Generate my custom rc-files next:
     rcfiles --populate-this-dir=/Depot/Chroot/AUTOGENERATED/
     rcfiles
     rcfiles --populate-this-dir=/AUTOGENERATED/
-    ry gcc --chroot --dont-symlink
-    ry ncurses --dontuseconfigureoptions --chroot
-    ry zlib --chroot
-    ry bison --static --chroot
-    ry m4 --chroot
-    ry curl --chroot
-    ry isl --chroot
-    ry flex --chroot
-    ry nasm --chroot
-    ry gc --chroot
-    ry tar --chroot
-    ry texinfo --chroot
-    ry openssl --chroot
-    ry libelf --chroot
-    ry elfutils --chroot
-    ry ccache --chroot
-    ry lzma  --chroot
-    ry cmake --chroot
-    ry file --chroot
-    ry pkgconfig --chroot
-    ry gperf --chroot
-    ry popt --chroot
-    ry git --chroot
-    ry pcre1 --chroot
-    ry pcre2 --chroot
-    ry libunistring --chroot
-    ry gettext --chroot
-    ry check --chroot
-    ry libxml2 --chroot
-    ry mtools --chroot
-    ry gzip --chroot
-    ry doxygen --chroot
-    ry strace --chroot
-    ry valgrind --chroot
-    ry graphite2 --chroot
-    ry tcl --chroot
-    ry expect --chroot
-    ry dejagnu --chroot
-    ry patch --chroot
-    ry libogg --chroot
-    ry sqlite --chroot
-    ry libpciaccess --chroot
-    ry libdrm --chroot
-    ry pixman --chroot
-    ry llvm --chroot
-    ry enchant --chroot
+    rbt gcc --chroot --dont-symlink
+    rbt ncurses --dontuseconfigureoptions --chroot
+    rbt zlib --chroot
+    rbt bison --static --chroot
+    rbt m4 --chroot
+    rbt curl --chroot
+    rbt isl --chroot
+    rbt flex --chroot
+    rbt nasm --chroot
+    rbt gc --chroot
+    rbt tar --chroot
+    rbt texinfo --chroot
+    rbt openssl --chroot
+    rbt libelf --chroot
+    rbt elfutils --chroot
+    rbt ccache --chroot
+    rbt lzma  --chroot
+    rbt cmake --chroot
+    rbt file --chroot
+    rbt pkgconfig --chroot
+    rbt gperf --chroot
+    rbt popt --chroot
+    rbt git --chroot
+    rbt pcre1 --chroot
+    rbt pcre2 --chroot
+    rbt libunistring --chroot
+    rbt gettext --chroot
+    rbt check --chroot
+    rbt libxml2 --chroot
+    rbt mtools --chroot
+    rbt gzip --chroot
+    rbt doxygen --chroot
+    rbt strace --chroot
+    rbt valgrind --chroot
+    rbt graphite2 --chroot
+    rbt tcl --chroot
+    rbt expect --chroot
+    rbt dejagnu --chroot
+    rbt patch --chroot
+    rbt libogg --chroot
+    rbt sqlite --chroot
+    rbt libpciaccess --chroot
+    rbt libdrm --chroot
+    rbt pixman --chroot
+    rbt llvm --chroot
+    rbt enchant --chroot
     # Compiling glibc should come last:
-    ry glibc --chroot --do-not-symlink --do-not-run-ldconfig
+    rbt glibc --chroot --do-not-symlink --do-not-run-ldconfig
 
 Do not forget to also copy a statically compiled
 version of busybox.
@@ -6755,8 +6604,8 @@ on the commandline:
 
 Or more specifically have a look at these two examples:
 
-    ry harfbuzz --use-cmake
-    ry zlib --trad --use-cmake
+    rbt harfbuzz --use-cmake
+    rbt zlib --trad --use-cmake
 
 Note that the **target build system** has to support cmake, in order
 for this to work. You can often find out whether cmake-support
@@ -6777,7 +6626,7 @@ added to the **RBT project**.
 
 Use it like so:
 
-    ry initng --release
+    rbt initng --release
 
 More options may be added in the future like this. For now, only
 this shortcut to **-DCMAKE_BUILD_TYPE=Release** exists.
@@ -6790,8 +6639,8 @@ USB stick**, or for any other similar use case, then the following
 API may be of help to you, accessible via this commandline
 variant:
 
-    ry --copy-these-archives=ruby,php,python
-    ry --copy-archives=kde5_plasma
+    rbt --copy-these-archives=ruby,php,python
+    rbt --copy-archives=kde5_plasma
 
 The latter in particular will copy all the different KDE5-plasma
 components onto a USB stick. This was the original use case as
@@ -6803,7 +6652,7 @@ programs on that machine.
 Note that you could also, in principle, **use abbreviations**
 here:
 
-    ry --copy-these-archives=xorgser
+    rbt --copy-these-archives=xorgser
 
 This would copy the local directory containing the xorg-server
 tarball, rather than the user being required to input "xorg-server".
@@ -6821,11 +6670,11 @@ If you only wish to copy a single source archive to the
 current working directory then you can use an API such
 as the following:
 
-    ry --copy-source=php
+    rbt --copy-source=php
 
 A few aliases exist to the above, such as:
 
-    ry --copy-this-archive=bison
+    rbt --copy-this-archive=bison
 
 I am not yet sure whether I should unify this distinction
 (**archive** versus **archives**) or not, but for the time 
@@ -6907,11 +6756,11 @@ annoying bug down and squished it.
 If you wish to quickly see all components that belong to, e. g. the
 compile chain forming xfce, then you can use this variant:
 
-    ry --show-components=xfce
+    rbt --show-components=xfce
 
 Similarly to do so for ruby, try:
 
-    ry --show-components=ruby_addons
+    rbt --show-components=ruby_addons
 
 ## Chained compilation
 
@@ -6929,11 +6778,11 @@ added to RBT.
 
 To compile the mate-desktop, for example, try:
 
-    ry --chained=mate
+    rbt --chained=mate
 
 To compile xfce, try:
 
-    ry --chained=xfce
+    rbt --chained=xfce
 
 Take note that this is not very sophisticated right now. A
 proper dependency manager requires more error checking
@@ -6952,8 +6801,8 @@ For example, KDE or KDE Plasma or mate-desktop.
 If you want to find out which programs are part of a particular
 chain, you can try any of the following:
 
-    ry --show-chain=plasma
-    ry --show-compile-chain-of=mate
+    rbt --show-chain=plasma
+    rbt --show-compile-chain-of=mate
 
 The first variant would show the proper compile chain that ought to be
 usable for KDE plasma; the second variant would show the proper 
@@ -6970,13 +6819,13 @@ that way, as they are registered in the file **chained_programs.yml**.
 For example, to try to batch-compile the KDE5 applications framework,
 you can try the following command:
 
-    ry --batch-compile=kde_apps
-    ry --batch-compile=kde-plasma
+    rbt --batch-compile=kde_apps
+    rbt --batch-compile=kde-plasma
 
 Or, simpler:
 
-    ry --kde-framework
-    ry --compile-kde-framework
+    rbt --kde-framework
+    rbt --compile-kde-framework
 
 Keep in mind that the **prior dependencies** ought to have been installed
 already for this to work (that is, <b>to have compiled successfully</b>
@@ -6987,13 +6836,13 @@ Since **as of July 2018**, a few simpler shortcuts exist as well.
 For example, to compile all programs of the **KDE5 foundation**,
 you can simply use the following command:
 
-    ry --compile-kde-foundation
+    rbt --compile-kde-foundation
 
 You can also manually specify which programs you may wish to
 **batch-compile** (that is, to compile them one after the
 other). The following **example** shows how this can be done:
 
-    ry --compile-these-programs=make,sed,awk,coreutils,utillinux,gawk
+    rbt --compile-these-programs=make,sed,awk,coreutils,utillinux,gawk
 
 This would specifically compile these programs in the given order,
 e. g. starting with **make**, over to **sed**, **awk**,
@@ -7004,8 +6853,8 @@ n programs of, for example, KDE.
 
 For example:
 
-    ry --kde1-first=10
-    ry --kde1-first=20
+    rbt --kde1-first=10
+    rbt --kde1-first=20
 
 This would compile the first 10 or first 20 programs of the 
 **KDE5 foundation** stack. Why has this functionality been
@@ -7058,7 +6907,7 @@ commandline flag can be used for this.
 
 Example:
 
-    ry tiff --ntrad --use-autoconf
+    rbt tiff --ntrad --use-autoconf
 
 ## Bootstrapping on a new system
 
@@ -7080,33 +6929,14 @@ will attempt to compile them one after the other, starting
 with the smallest program first (otherwise these will be
 appended to the array, and be handled last).
 
-## Sinatra-interface
-
-The RBT project comes with a small sinatra-wrapper.
-
-Not a lot of functionality is available as of yet (**November 2020**),
-but more functionality will be added over the coming months.
-
-Right now you can **view** the content of a registered 
-program. In the future you may also be able to install/
-or remove/ an installed program. Be careful when doing
-so, as things may not work properly - if possible use 
-the commandline variant instead.
-
-Note that you can also start the sinatra-interface from
-the commandline via:
-
-  rbt --sinatra
-  rbt --sinatra & # if you want to start it as a background service
-
 ## Checking a remote git repository
 
 If you wish to quickly download the git-source of a program,
 say **binutils**, you could use any of the following options:
 
-    ry binutils --check-source
-    ry binutils --git
-    ry mpv --git-download
+    rbt binutils --check-source
+    rbt binutils --git
+    rbt mpv --git-download
 
 This would, in principle, work for all programs that are
 hosted via git. A requirement is that the .yml file at hand
@@ -7137,7 +6967,7 @@ If you want to copy all .h files from, say, glibc, to the current
 working directory, then you could do it via this commandline 
 flag:
 
-    ry glibc --copy-headers-from=/usr/include
+    rbt glibc --copy-headers-from=/usr/include
 
 I needed this functionality so that I could copy a glibc version
 installed into the **/usr** or **/** prefix, into
@@ -7145,9 +6975,9 @@ installed into the **/usr** or **/** prefix, into
 
 There also exists a slightly simply API:
 
-    ry glibc --copy-headers
-    ry glibc --copy-headers-into-pwd
-    ry glibc --copy-headers-to-pwd
+    rbt glibc --copy-headers
+    rbt glibc --copy-headers-into-pwd
+    rbt glibc --copy-headers-to-pwd
 
 The two variants are not completely the same, though. The second
 variant will only copy .h files that reside in an AppDir-like
@@ -7169,19 +6999,19 @@ You can also do so from the commandline, if your target is the
 
 Example:
 
-    ry --query-headers
+    rbt --query-headers
 
 You can designate another target directory to be checked for
 .h files, via a commandline flag such as:
 
-    ry --query-headers=/usr/local/include/
+    rbt --query-headers=/usr/local/include/
 
 This functionality also works for binaries found under **/usr/bin/**,
 by issuing something like:
 
-    ry --query-programs
-    ry --query-programs?
-    ry --attribute?
+    rbt --query-programs
+    rbt --query-programs?
+    rbt --attribute?
 
 This is equivalent to the following ruby code:
 
@@ -7190,7 +7020,7 @@ This is equivalent to the following ruby code:
 If you want to determine all headers of, say, the program called
 **ruby** then you can issue the following command:
 
-    ry --headers-of=ruby
+    rbt --headers-of=ruby
 
 ## Using header files such as ao.h or udev.h as input for compilation
 
@@ -7205,7 +7035,7 @@ the name of the program.
 
 Consider the following:
 
-    ry udev.h ntrad
+    rbt udev.h ntrad
 
 This would replace **udev.h** with **eudev**, and compile it in
 a non-traditional (== **AppDir**) way.
@@ -7241,14 +7071,14 @@ ruby code, you can modify it via
 To find out which compiler will be used you can use the following
 from the commandline:
 
-    ry --compiler?
+    rbt --compiler?
 
 If you wish to compile not only LLVM from source, but also the
 **clang-compiler** and the **compiler-rt add-ons**, then you
 can use the following commandline to do so:
 
-    ry llvm --include-clang-for-compilation
-    ry llvm --compile-clang
+    rbt llvm --include-clang-for-compilation
+    rbt llvm --compile-clang
 
 Make sure that you have the necessary archive tarballs in the
 corresponding directories for this to work, though. (This
@@ -7263,7 +7093,7 @@ You can also permanently enable **clang** on the commandline.
 
 Example for this:
 
-    ry --permanently-use-clang
+    rbt --permanently-use-clang
 
 (This will modify the .yml file, so you can do the very same on your 
 own; the feature exists merely as a convenience tool, to avoid users 
@@ -7294,7 +7124,7 @@ exists.
 
 Example:
 
-    ry libx11 --backup
+    rbt libx11 --backup
 
 This will compile the program called **libx11** into 
 /home/Programs/Libx11/1.7.0/ or wherever else your 
@@ -7315,14 +7145,14 @@ If you wish to compile all of **XFCE** into a single directory, such
 as <b>/Programs/Xfce/4.12.0/</b>, then you can issue the following
 command:
 
-    ry --xfce-into-standalone-dir
+    rbt --xfce-into-standalone-dir
 
 Some aliases exist to the above commandline flag, such as:
 
-    ry --compile-xfce-components-into-one-standalone-directory
-    ry --compile-xfce-components-into-a-standalone-directory
-    ry --compile-xfce-components-into-standalone-directory
-    ry --use-xfce-prefix
+    rbt --compile-xfce-components-into-one-standalone-directory
+    rbt --compile-xfce-components-into-a-standalone-directory
+    rbt --compile-xfce-components-into-standalone-directory
+    rbt --use-xfce-prefix
 
 This functionality is experimental as of **October 2018**, and
 relies on a hardcoded path; but in the future, this functionality
@@ -7337,7 +7167,7 @@ page called **Environment settings**.
 
 You can also batch-compile the XFCE components via:
 
-    ry --compile-xfce
+    rbt --compile-xfce
 
 If you already have XFCE installed/compiled, then you can use
 the following code to report the versions of the XFCE
@@ -7371,7 +7201,7 @@ commandline switch **--use-meson**.
 
 Usage example:
 
-    ry glib --use-meson
+    rbt glib --use-meson
 
 Note that presently (2018) this does not work perfectly well,
 which may be understandable since meson/ninja is fairly new,
@@ -7383,6 +7213,441 @@ be given to meson:
 
     --wrap-mode=nodownload
 
+## Deprecations within the RBT project
+
+Over the years, quite a lot of old code was removed or rewritten. As I can
+not keep track of everything mentally, I will use this subsection to note
+down when something was removed.
+
+- In the past, cmake configure options were stored as **configure_options: **
+in the corresponding .yml file. However had, since some time the new
+option **cmake_configure_options: ** exists. For about two years, if
+no such cmake_configure_options was existing, yet cmake was used as
+the build system, then the RBT scripts would assume that the user
+wanted to make use of **configure_options** anyway, so this was used.
+
+In April 2021, though, I decided that it is cleaner to only use
+**cmake_configure_options** and thus deprecate that old behaviour where
+**configure_options** could be substituted.
+
+## Licence of this project
+
+Copyright 2021 Robert A. Heiler
+
+Up until the beginning of **April 2021**, the rbt project was
+using the GPL-2.0 licence (no later clause).
+
+In **April 2021**, though, I decided to switch to the **MIT**
+instead for this project. The older GPL code will remain 
+available for some time, most likely at the least a full
+year, perhaps even longer. But the older code is now 
+deprecated as far as I am concerned; others would have to
+maintain it. I only focus on the MIT variant now.
+
+You can read this licence here:
+
+https://opensource.org/licenses/MIT
+
+Why was it decided to switch to MIT rather than GPL?
+
+Well, there are several reasons.
+
+First, and most importantly: while I will continue to maintain
+the project here for a long while (I am using it on a daily
+basis), it is not really a project I particular "care" about
+in the sense of wanting to restrict how users use it. It is
+just a ruby gem, not anything I am using for a "mission-critical
+project". It also is not important to me in regards to my 
+financial status; nothing against donation by kind people, 
+but I did not create the project for any of that. I created
+the project mostly because I needed to compile software or
+otherwise install software.
+
+Second, though, the GPL is a strict licence. This can be very
+useful - see the Linux Kernel. You also depend less on 
+corporations controlling the software stack, so the GPL has
+very laudable goals. But ... is the GPL really important for
+a project like this one here? I am not sure. I think you can
+already "generate value" if a project is useful, so the 
+licence then is of a secondary concern, in particular when
+it is a smaller project.
+
+These were my two main reasons. There are a few smaller issues,
+such as the MIT licence being much simpler to use and adhere
+to, but by and large these were the main reasons.
+And if a company ever decides to want to make use of RBT
+then I feel flattered - it means that the project has some
+real value, right? Otherwise people would not use it.
+
+Be wary of bugs, though; even the MIT comes with a "no
+warranty" clause, so always test things first in a secure
+environment. While I use this project since over a decade,
+my use case may not be the same as how other people use
+the project.
+
+## GNOME
+
+The gnome-project tarball archives can be found here,
+as I last verified this in **April 2021**:
+
+    https://download.gnome.org/sources/?C=M&O=D
+
+The releases usually have even numbers for **stable releases**; and
+odd numbers for **unstable releases**.
+
+I myself used to stay on the "bleeding edge", thus using unstable
+releases, to try to see what is new - but after some time, running
+into problems here and there, I am now convinced that the stable
+releases are MUCH much better, since you will have less problems
+or errors in the long run. Every time I encountered a problem related
+to an unstable release, I ended up investing via my time trying to
+fix the problem at hand, which often was not possible, and quite
+frustrating anyway. In the end I did waste way too much time for
+too little gain, so I decided to stop making use of unstable
+gnome releases. Past that point I am using only the stable 
+tarball releases, unless there is some specific reason why
+not - but, 99% of the time I settle for stable releases.
+
+I added some code to the class that automatically download 
+gnome-packages, to only consider **even numbers** when doing
+such a download. But this behaviour can be toggled via a
+**commandline switch** on the commandline, anyway - so 
+the subsection here just explains as to why I personally 
+**favour stable gnome releases** really.
+
+You can also compile the gnome components in an ordered fashion
+if you wish to compile them, by making use of **numbers**.
+(This also works for kde, xfce, xorg, mate-desktop, games
+and the like.)
+
+Specific examples:
+
+    rbt gnome1
+    rbt gnome2
+    rbt gnome3
+    rbt gnome4
+
+And so forth.
+
+To **batch compile** most of these components, try:
+
+    rbt gnome1..200
+
+If you want to see what entries are available on the
+gnome FTP site, try this API:
+
+    RBT.show_the_gnome_ftp_listing
+
+## class RBT::ShowVersionsOfThesePrograms
+
+class **RBT::ShowVersionsOfThesePrograms** can be used to
+quickly compare the versions of different programs.
+
+You can use it from the commandline via bin/show_versions_of_these_programs:
+
+    show_versions_of_these_programs ruby python php
+
+Or from within ruby itself via:
+
+    require 'rbt/utility_scripts/show_versions_of_these_programs.rb'
+    RBT::ShowVersionsOfThesePrograms.new(%w( ruby python php ))
+
+The output would then be something like:
+
+    ruby:                          3.0.0
+    python:                        3.9.3
+    php:                           8.0.3
+
+This is really just a quick way to show the versions of programs
+you may be interested in. If typing **show_versions_of_these_programs**
+is too cumbersome simply alias it to a shorter name.
+
+## Removing outdated (local) archives
+
+I tend to batch-update the RBT project quite frequently. As a result
+of this, I end up having lots of local archives, usually in the
+**.tar.xz** format. Since removing these manually is annoying
+and time-consuming, a class has been added on **07.01.2020**,
+called **RBT::RemoveOutdatedArchives**.
+
+This class is presently not very flexible, since I only used it
+to remove a specific set of programs - mostly KDE-related
+packages.
+
+For example, one specific invocation may go like so:
+
+    require 'rbt/utility_scripts/remove_outdated_archives.rb'
+
+    RBT::RemoveOutdatedArchives.new(:kde_plasma)
+
+This would **remove all outdated archives** belonging to the
+**KDE Plasma stack**.
+
+More examples:
+
+    RBT::RemoveOutdatedArchives.new(:kde_applications)
+    RBT::RemoveOutdatedArchives.new(:kde_foundation)
+
+The above would remove all outdated KDE5 applications (if all
+goes well), respectively all of KDE5 foundation.
+
+I run this from the commandline actually, so I tend to
+use:
+
+    remove_outdated_archives :kde_applications
+
+In the future this class may be extended, to allow more 
+groups of programs to be batch-removed, but for now this
+has to suffice.
+
+Also note that whenever this paragraph refers to KDE, it refers
+to **KDE5**. This may change in the future (e. g. KDE6 release
+and similar), but for now (January 2020) it is up-to-date and
+thus correct.
+
+**Recommendation**: do not invoke this class unless you are
+absolutely certain that you want to get rid of local, outdated
+archives. I recommend to do a backup onto an external storage
+device first. As said, this class was not very thoroughly
+tested, so be cautious.
+
+## ccache
+
+There is a configuration setting as part of the RBT project,
+called <b>use_ccache</b>. If this is set to yes, aka **enabled*,
+then the RBT project, in particular RBT::Compile, will attempt
+to **make use of ccache for compilation**.
+
+This may speed up repeated compilation cycles of the same program
+quite efficiently, so if you compile many different programs 
+again and again, it is recommended to use ccache.
+
+If you do not need ccache or do not have it on the given computer
+system, you can disable the use of ccache permanently, as far
+as RBT is concerned, via this commandline invocation:
+
+    rbt --permanently-disable-ccache
+
+Alternatively you can also modify the file at
+<b>rbt/yaml/configuration/use_ccache.yml</b>, which is
+where the configuration setting as to whether to use
+ccache or not, resides. The allowed values are
+<b>true</b> or <b>false</b>, <b>yes</b> and <b>no</b> (for
+all configuration values, by the way).
+
+If you only want to **disable ccache for the current run**, then you can
+use any of the following variants (here we assume that the target 
+program you wish to compile is <b>fluxbox</b>):
+
+    rbt fluxbox --disable-ccache 
+    rbt fluxbox --do-not-use-ccache
+    rbt fluxbox --no-ccache
+    rbt fluxbox --ccache-
+
+A manual use of ccache would go like this:
+
+    ccache gcc # files to be compiled go in here
+
+## Installing the registered python addons
+
+The RBT project has some python add-ons registered. These can
+be installed via either of the following:
+
+    rbt --enable-python-addons
+    rbt --compile-python-addons
+    rbt --python-addons
+
+You will most likely not need this, since this is catered to my
+own use case (since I have to batch-install things on a new
+computer, for example). But the option exists nonetheless
+since as of **March 2019**. I use it typically after I have
+compiled a new python version. Once that python version has
+been installed, I compile (or just install) the python
+addons.
+
+## Show which files will be installed by a given program
+
+To show which files are installed by, say, the program
+called **htop**, try this:
+
+    rbt htop --show_which_files_will_be_installed
+
+## Forgetful API design
+
+Over the years, tons of code has been added or removed; some
+of the existing code is not called.
+
+Since I tend to forget what exists and what does not, I
+added this subsection in 2021 as a brief memo for (future)
+me.
+
+    return_possible_abbreviation_to_this_input(i)
+    # ^^^ This can be used to return all possible
+    # abbreviations to the given input at hand.
+
+## Changing the prefix in any given Makefile
+
+Since as of **03.05.2019** (3rd May of 2019) it is now possible to change
+the prefix in a given **Makefile**, via class **RBT::ChangePrefix**.
+
+This class can modify the PREFIX variable in that Makefile. It was added
+so that we can change the PREFIX target of any Makefile on the fly.
+
+Currently it does not have a lot of configurable options but this may
+change in the future. For the time being, the first argument should
+be **the path to the Makefile** that should be modified.
+
+## Configure options saved
+
+The **configure options** that were used in order to compile a particular
+program at hand, will be stored in the file called
+<b>configure_command_database.yml</b>, which can typically be found
+at a location such as:
+
+    /Depot/Temp/rbt/configure_command_database.yml
+
+The entries in this yaml file may look like this:
+
+  minuet: cmake -DCMAKE_INSTALL_PREFIX=/usr/ /Depot/Temp/rbt/minuet-18.12.3/ 2>&1
+
+So the format is - first comes **the name of the program**; followed by the
+particular command that was invoked.
+
+Note that this will **only** be stored in that .yml file if no problem was
+encountered during compilation - thus, assumingly, would mean that the
+compilation was successful or at the least continued without major
+problems/errors encountered.
+
+The primary reason as to why this functionality was added was so that the
+user can quickly look at that .yml file and see which configure option was
+used to compile a program. This may be useful at some later time when you
+wish to find out what went wrong (if something went wrong) or perhaps
+if you can not access the xorg-server but need to re-compile something.
+
+## Configure options and passing additional configure options
+
+The content of the various .yml files distributed as part of the **rbt**
+gem may have an entry called **configure_options**. For example,
+the **htop.yml** entry may look like this:
+
+    disable-unicode
+
+Which will be expanded into **--disable-unicode** if that .yml file
+is **expanded**.
+
+The entries that are listed under **configure_options** are usually
+those that will keep track of the arguments that a user may normally
+pass as arguments towards GNU **./configure**, such as
+**--enable-static** or **--disable-shared**.
+
+For example:
+
+    ./configure --prefix=/usr --enable-static
+
+Over the years, new and different build systems, such as meson/cmake or
+cmake, emerged. They often would use different syntax as well, 
+such as **-Dlibpsl=false** for meson or **-DDONT_USE_INTERNAL_LUA=Off**
+for cmake.
+
+Largely because of these reasons, the rbt project had to allow for
+configure options sent to meson or cmake specifically, due to the
+difference in syntax.
+
+In **December 2018**, a new syntax was added for the .yml files,
+for meson specifically, called **meson_configure_options**. A
+similar option exists for cmake, called **cmake_configure_options**.
+
+An example for this in regards to meson can be found in the 
+file **networkmanager.yml**.
+
+Some of these configure options can be directly passed to an
+instance of class **RBT::Compile** as well.
+
+For example, if you wish to use **--enable-shared** then you can
+simply pass it, like so:
+
+    rbt htop --enable-shared
+
+This will simply pass in the configure option **--enable-shared**.
+
+In the future, more options will probably be added and allowed.
+
+Some options may be translated into the equivalent cmake-option, if
+cmake is used, but for the time being, this is presently (November
+2018) not well supported. Stay tuned for later changes in this regard.
+
+Since as of **November 2019**, the configure options that were used
+to compile a program, will also be stored into the target
+file at **Resources/configure_options.md** if it was installed
+via an AppDir prefix (e. g. **/Programs/Ruby/2.6.5/** and
+similar), if the compilation was a success **and** if there
+was **at the least one** configure options - thus, empty Strings
+will not be stored.
+
+Note that this file will **only** store the actual configure_options
+that were used; for the **full** configure-like command, see the
+corresponding file in the same directory, whose name is
+**full_configure_command.md**.
+
+In the older rbt releases, it was possible to re-purpose the
+entry called **configure_options** for cmake and meson. In
+**April 2021** this was deprecated. It is cleaner, simpler
+and more logical to use separate entries for GNU configure,
+meson/ninja and cmake instead.
+
+## md5sum
+
+The expanded cookbook dataset includes the **md5sum** entry
+for a given archive, such as **foobar-1.0.tar.xz**.
+
+This md5sum entry is calculated locally on my home system, where
+the "md5sum" binary is run on a .tar.xz archive. So if you get
+another value, have a look whether you get the same value
+when the package is also in the **.tar.xz format**.
+
+## Sinatra-interface
+
+The RBT project comes with a small **sinatra-wrapper**, for use
+on the **www**.
+
+Not a lot of functionality is available as of yet (**November 2020**),
+but more functionality will be added over the coming months and
+years. Stay tuned. Some more functionality was added in
+**April 2021**.
+
+Right now you can **view** the content of a registered 
+program. In the future you may also be able to install/
+or remove/ an installed program. Be careful when doing
+so, as things may not work properly - if possible use 
+the commandline variant instead, as that one has been
+tested more thoroughly.
+
+Note that you can start the sinatra-interface from
+the commandline via:
+
+    rbt --sinatra
+    rbt --sinatra & # if you want to start it as a background service
+
+To view a program, either use the input-field, or
+simply use an URL such as this:
+
+    http://localhost:5580/view/php
+
+Replace the URL port with whatever port you want to use; this
+is currently hardcoded and defined in the constant
+**USE_THIS_PORT**.
+
+In order for this to work, the program must have been
+registered as part of the RBT project.
+
+You can also display the **available programs**, via
+the sinatra interface, by using:
+
+    http://localhost:5580/available_programs
+
+For more documentation, have a look at
+**doc/sinatra/README.md**.
+
 ## Last updated programs
 
 The following programs were updated with this release,