updated README.md, added to do list, fixed separator length, version info swith to english

README.md

@@ -15,8 +15,9 @@ using Debian GNU/Linux, Devuan and different flavors of Ubuntu.
   - [3.5. Basic module structure](#35-basic-module-structure)
 - [4. Error code table](#4-error-code-table)
 - [5. Contact and more information](#5-contact-and-more-information)
-  - [5.1. How to contribute?](#51-how-to-contribute)
+  - [5.1. New users](#51-new-users)
-  - [5.2. Website and maintainor](#52-website-and-maintainor)
+  - [5.2. How to contribute?](#51-how-to-contribute)
+  - [5.3. Website and maintainor](#52-website-and-maintainor)
 
 ## 1. Getting started
 You should consider reading that document entirely before use. If you need
@@ -29,10 +30,10 @@ it would be a good idea to submit your module to init.sh source base.
 ## 2. Why init.sh?
 Short answer: why not?
 
-Long answer: Even if I vallue tools like Puppet or Ansible, I always thought
+Long answer: Even if I value tools like Puppet or Ansible, I always thought that
-that such great and complex systems are very nice for big infrastructures. But,
+such great and complex systems are very nice for big infrastructures. But, on a
-on a much smaller scale, or if you need something fast to deploy and adapt to
+much smaller scale like small business, or if you need something fast to deploy
-your needs, such big tools are somehow overkill.
+and easy to adapt to your needs, such great tools are somehow overkill.
 
 I wanted something simple and as universal as possible to manage many different
 unique servers in my small local foundations. I started with a lot of long
@@ -40,12 +41,12 @@ hardcoded monolitic scripts where I had to rewritte many things on every new
 infrastructures I wanted to manage. As it was a fastidious job, I started to
 rewritte and redesign everything with a common architecture and code, modular
 and easily adaptative. As I don't know any tools in that market scale, I decided
-to publish.
+to publish and share that work, in the hope I can be usefull.
 
 ## 3. Design
 **init.sh** relies on three different elements to work:
 
-- the ```init.sh``` script, which provide a simple framework and libraries to do
+- the ```init.sh``` script and libraries, which provide a simple framework to do
 simple tasks and embed system dependent functions to provide system independent
 function calls.
 - modules that actually do the job, as possible on a system independent way
@@ -127,6 +128,13 @@ your own configuration. At this point a deeper analysis of command line option
 will be done, triggering errors in case of inconsistency or incompatible
 options.
 
+After that all the configured modules with the ```$MODULE_LIST``` variable are
+loaded to be availble for execution. Note that even function that might not be
+used will be loaded. At this point everything that will be necessary for checks
+and modification will be available in the scripts esecution environment. If the
+```--shell``` command line option is given, the subshell is loaded just after
+this point.
+
 Finally, checking processes are launched in their declaration order (cf.
 configuration file). A module depency check is made prior to the module specific
 checks unless the ```--no-deps``` option is given or if a manual module list
@@ -174,7 +182,7 @@ of OS detection:
 | **arch**    | ```SYS_ARCH``` | This is the system architecture, like x86_64, i386, arm64, etc. |
 | **dist**    | ```SYS_DIST``` | The name of the Linux distribution as reported by */etc/os-release*. |
 | **version** | ```SYS_VER```  | Version of the distribution. If you run a rolling release and no version is provided by your */etc/os-release* file, the main version of the Linux kernel will be used (e.g. 5.4 for any version of 5.4.x kernel branch). |
-| **codename**| ```SYS_CODE``` | If your distribution profide a version codename, it will be set with it. |
+| **codename**| ```SYS_CODE``` | If your distribution provide a version codename, it will be set with it, elsewhere it will remain unset. |
 
 The configuration files are loaded if exists in the following order:
    1. arch.conf.sh
@@ -205,16 +213,16 @@ underscore is completely forbidden.
 
 Any submitted module to the central repository will have module name in lower
 case with underscore to separate words and ease reading, and variable name upper
-case with the same underscore as word separator.
+case (except local variables) with the same underscore as word separator.
 
 ### 3.5. Basic module structure
 
 Please note that modules are not supposed to contain any specific code for a
 platform or a distribution, even if nothing block you doing so. It is highly
-recommended to use configurations files to introduce any platform dependent
+recommended to use automatic configurations files to introduce any platform
-code. Additionally, it will be possible to create system dependent modules using
+dependent code and variables. Additionally, it will be possible to create system
-naming convention in the style module_name.debian.x86_64.sh (awaited for version
+dependent modules using naming convention in the style
-2 of init.sh).
+```module_name.debian.x86_64.sh``` (awaited for version 2 of init.sh).
 
 In the following example, ```@template@``` have to be replaced with the name of
 your module with the filename ```@template@.sh```. You can automatically create
@@ -226,11 +234,13 @@ sed -e "s/@template@/module_name/g" -e "/^# .*/d" -e "s/^##/# /" template > \
 ```
 
 Versioning modules is up to you, but the recommended behavior follows some
-standard rules. Considering a numbering as x.y.z:
+standard rules, not artificially increasing version numbers in a stupid fight of
+who will have the biggest like Google or Firefox. Considering a numbering as
+x.y.z:
 
 - x might be incremented in case of major change, rewriting or different
 approach on the way to have the job done, the used variable could massively
-change;
+change and jeoppardy compatibility;
 - y might be incremented in case of simple functionality addition or basic
 improvements, existing variable might not change, but new ones could appear;
 - z might be incremented only when correcting problems and/or bugs (+n fix ⇒ +n
@@ -254,27 +264,39 @@ implies an increment of a version number in the code **and** a git commit.
 # Module version
 export VER_@template@="0.0.1"
 
+# Module dependencies (contains other module names if dependencies exists)
+export DEPS_@template@=""
+
 # Module main code
 @template@()
 {
-    # Code
+    : # Code
 }
 
 # Pre-run checks code
 precheck_@template@()
 {
-    # Code
+    : # Code
+}
+
+# Optionnaly, cron mode code
+cron_@template@()
+{
+    : # Code
 }
 
 # Any public fonction have to be exported
 export -f @template@
 export -f precheck_@template@
+
+# If cron_@template@ exists :
+export -f cron_@template@
 ```
 
 Unexported template function will work but won't be available in the integrated
-debugging shell (see ```--shell``` option).
+debugging shell (see ```--shell``` option), so it's not encouraged.
 
-An optionnal ```cron_@template@``` function allows you to define code that will
+The optionnal ```cron_@template@``` function allows you to define code that will
 be executed in cron mode. Check [cron documentation](./doc/cron.md) for more
 details.
 
@@ -315,23 +337,35 @@ provided module, please contact the author. Of course, if you also have a patch,
 your mail will be even more welcomed!
 
 ## 5. Contact and more information
+### 5.1. New users
+As this project is very new and as I have no idea of who will use it, if you do
+so, I'll be very happy if you simply mail me to let me know, especially if you
+don't plan to contribute.
 
-### 5.1. How to contribute?
+### 5.2. How to contribute?
-If you want to contribute, the best is to use git and push your changes in a
+You are free to improve and contribute as you wish. If you have no idea what to
-branch you made for that purpose. If you want to submit a patch, you can send it
+do or want some direction, you can check the [to do list](./doc/todo.md),
-by mail to the maintainor of init.sh.
+containing desired future improvements. Make sure you always have the latest
+development version before starting your work.
+
+It's heavily recommended to use git to obtain latest copy of init.sh tree. Make
+sure your git is configured for contribution. Please contact me to obtain push
+authorisations, or, if you want to submit a patch, you can send it by mail to
+the maintainor of init.sh.
 
 You can improve anything you want, but keep in mind init.sh have to stay small
 and simple. If your idea cannot be written using Bash scripting, maybe that
 means you're going to far in the improvement.
 
 Code written in Python or Perl might be accepted as long as it's not mobilizing
-a lot of dependencies (forget big framework). Core script will remain in Bash
+a lot of dependencies (forget big framework). Anything that need installing
-whatever the evolutions of init.sh will be.
+packages not provided in minimal Debian installation will be rejected. Anyway,
+core scripts will remain in Bash whatever the evolutions of ```init.sh``` will
+be.
 
-### 5.2. Website and maintainor
+### 5.3. License, website and maintainor
-Everything except configuration files are licensed under BSD-3 license. Please
+Everything except configuration files is licensed under BSD-3 license. Please
-check license file.
+check license file allong this one.
 
 Please check [https://www.geoffray-levasseur.org/init](https://www.geoffray-levasseur.org/init).
 Please note that this website is still under construction and needs some more

doc/todo.md

@@ -0,0 +1,21 @@
+# This is init.sh to do list
+
+There's no specific order in that list. All that is subject to appear in version
+1.x.y of ```init.sh```.
+
+ * Better error management system
+ * Fix ```--keep-going``` option not properlly working
+ * Add a function for booleans to accept true, yes and 1, and false, no and 0 answers
+ * Add network configuration module
+ * More modules
+ * Add support for CentOS
+ * Add support for Slackware
+ * Add support for more distros including BSDs
+ * Improve output
+ * Add ```--quiet``` option to hide run commands output
+ 
+Here is ideas for version 2 of ```init.sh```:
+
+ * Support for system dependant modules
+ * Better configuration file design with a proper parser (ini style maybe)
+ * Configuration designer (CCmake style maybe), can't be done in Bash

lib/display.sh

@@ -130,7 +130,7 @@ separator()
 {
     echo -ne "$BYellow"
     local i=0
-    for i in {1..79}; do
+    for i in {1..$(( $(tput cols) - 1 ))}; do
         echo -n "-"
     done
     echo -e "$DEFAULTCOL"

lib/support.sh

@@ -78,7 +78,7 @@ show_version()
 {
     echo -e "${BWhite}init.sh${DEFAULTCOL} version ${BGreen}$VERSION${DEFAULTCOL}"
     echo ""
-    echo "Modules disponibles :"
+    echo "Available modules:"
 
     local mod=
     for mod in $MYPATH/modules/*.sh; do
@@ -96,7 +96,7 @@ show_version()
     unset mod
 
     if [[ $(id -u) -ne 0 ]]; then
-        echo -e "\n${BYellow}Attention :$DEFAULTCOL Ce script requiert les droits d'administration pour fonctionner."
+        echo -e "\n${BYellow}Warning:$DEFAULTCOL That script requires superuser rights to work."
     fi
 }
 export -f show_version