fatalerrors/init.sh
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

updated documentation

Browse Source
This commit is contained in:
fatalerrors
2021-12-09 19:55:13 +01:00
parent ebc5b50300
commit e91a746a14
2 changed files with 82 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

76
doc/dev.md
View File

@@ -1,7 +1,6 @@
# init.sh developer's reference
## Table of content
- [init.sh developer's reference](#initsh-developers-reference)
- [1. Getting started](#1-getting-started)
- [2. The aaa_error.sh file](#2-the-aaa_errorsh-file)
- [2.1. Functions](#21-functions)
@@ -59,6 +58,15 @@
- [9.1. Functions](#91-functions)
- [9.1.1. ```get_os_version```](#911-get_os_version)
- [9.1.2. ```set_sys_var <arch> <dist> <version> <codename>```](#912-set_sys_var-arch-dist-version-codename)
- [10. The zzz_main_fct file](#10-the-zzz_main_fct-file)
- [10.1. Functions](#101-functions)
- [10.1.1. ```read_commandline```](#1011-read_commandline)
- [10.1.2. ```chroot_bootstrap```](#1012-chroot_bootstrap)
- [10.1.3. ```load_autoconf```](#1013-load_autoconf)
- [10.1.4. ```load_configuration```](#1014-load_configuration)
- [10.1.5. ```process_commandline_and_vars```](#1015-process_commandline_and_vars)
## 1. Getting started
This is a developer's reference. It's not intended to be a manual, but a
reference for all internal functions, so you can easily build your own modules.
@@ -520,4 +528,68 @@ The following global variables will be set at the end of the execution:
- **```SYS_CODE```** for the distribution codename
The ```SYS_CODE``` variable won't be set if your distribution provides no codename.
## 10. The zzz_main_fct file
This file is used internally directly by the init.sh script. Its purpose is
only to lighten the main program file and those function are not supposed to be
used by any module or even more than once. Thus it's documented to help new
developpers to contribute.
### 10.1. Functions
#### 10.1.1. ```read_commandline```
That function consist in a loop that analyse command line one parameter after
the other. Most of command line parameters will result in the positionning of
some global variables. The following table details the variable with their type
associated to the corresponding parameter:
| Parameter | Variable | Type | Descrition |
|:--------------|:-------------------|:--------|:------------------------------|
| --help | *none* | *n/a* | Trigger help display directly and exit |
| --version | *none* | *n/a* | Trigger help display directly and exit |
| --module | MANUAL_MODULE_LIST | string | The following parameter will set a list of module to use |
| --check-only | CHECK_ONLY | boolean | Activate check only mode |
| --jump | JUMP | boolean | Activate no checks mode |
| --keep-going | KEEPGOING | boolean | Activate keep going option |
| --resume | RESUME | boolean | Activate resume mode if stage file exists |
| --no-root-check | NO_ROOT_CHECK | boolean | Activate option to not check if user is root |
| --no-deps | NO_DEPS | boolean | Activate not checking module dependencies option |
| --logfile | NEW_LOGFILE | string | The following parameter will be the log filename |
| --file | CONFFILES | string | The following parameter will be a configuration filename |
| --shell | RUN_SHELL | boolean | Activate the shell mode |
| --chroot | CHROOT_PATH | string | The following parameter will be the path to chroot in |
| --cron | CRON_MODE | boolean | Activate cron mode |
The function will do some basinc synthax checks. For exemple if you put an
option just after one supposing a value declaration, an error will be trigered
directly.
#### 10.1.2. ```chroot_bootstrap```
That function is called if a chroot option have been given. It's in charge of
performing the chroot, copying a full working directory structure of init.sh
tree. After that copy a chroot command is runned launching that new copy of
init.sh.
If the child init.sh end with error, the stage file is gathered in parent
directory tree to allow launching again the chrooted init.sh with the resume
option.
At the end the function will clean up removing the second copy of init.sh.
#### 10.1.3. ```load_autoconf```
That function will automatically load system specific configuration if file
exist in the following order:
1) ```auto/arch.conf.sh```
2) ```auto/distro.conf.sh```
3) ```auto/distro-arch.conf.sh```
4) ```auto/distro-version.conf.sh```
5) ```auto/distro-codename.conf.sh``` (if ```SYS_CODE``` defined)
6) ```auto/distro-version-arch.conf.sh```
7) ```auto/distro-codename-arch.conf.sh``` (if ```SYS_CODE``` defined)
Plaese note that a situation where no such file exists would lead to error. Most
of the time a basic package manager configuration will be required to make it
work.
#### 10.1.4. ```load_configuration```
#### 10.1.5. ```process_commandline_and_vars```

10
doc/todo.md
View File

@@ -4,7 +4,7 @@ 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
* Fix ```--keep-going``` option not properly working
* Add a function for booleans to accept true, yes and 1, and false, no and 0 answers
* Add network configuration module
* More modules
@@ -13,9 +13,15 @@ There's no specific order in that list. All that is subject to appear in version
* 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
What will never appear in that todo list (so don't ask) :
* Windows: don't ask for Windows support, it will never happens
* MacOS: same as above
* Base language change: the heart of init.sh is BASH, and will always be