updated documentations

This commit is contained in:
2021-10-27 13:57:58 +02:00
parent 3bb5a880d5
commit 029a5b7a0d
2 changed files with 50 additions and 18 deletions

View File

@@ -185,23 +185,20 @@ ending will filled with background color.
## 4. The filefct.sh file
### 4.1. Functions
#### 4.1.1. stdtime
Display date and time based on RFC 3339 standard but slightly modified so it can
be used in filename. Thus spaces are replaced by dash, and comas between hours,
minutes and seconds are removed.
That function takes no parameters and return its result on standard output.
#### 4.1.2. backupdist \<list_of_files_or_dirs\>
#### 4.1.1. backupdist \<list_of_files_or_dirs\>
That function will provide a backup of any given files or directories given in
command line. The backup will be named name.dist-timestamp, where name is the
original file or directory name and timestamp the date and time of the backup
as retuned by the ***stdtime*** function. If a file given in parameter don't
exists, the function will issue a warning and continue to the next.
If target file or directory is a symbolic link, the link will be resolved until
we backup the target on its side.
The function don't take any other parameters than file and/or directory names.
#### 4.1.3. installfile \<sources\> \<destination\>
#### 4.1.2. installfile \<sources\> \<destination\>
Install a list of file to the given destination. The source of the file can be
of three different orrigins, from highest to lowest priority:
- **repo/hosts/$HOSTNAME**: this allows to provide system specific configuration
@@ -218,7 +215,7 @@ to give an entire directory as a source.
The last parameter is always the destination. If the path do not exists, it
will be created automatically.
#### 4.1.4. appendfile \<source\> \<destination\>
#### 4.1.3. appendfile \<source\> \<destination\>
That function add the content of source file to destination file. The source
file can have defferent origins, following the same path priority as the
*installfile* function.
@@ -226,7 +223,7 @@ file can have defferent origins, following the same path priority as the
The destination file must exist and be on the root filesystem. Only two
parameters are accepted, the source and destination files.
#### 4.1.5. isdirempty \<directory\>
#### 4.1.4. isdirempty \<directory\>
That function take only one parameter, a path name and return 0 if the given
path don't exists or is empty. It will return one if there's at least one file
in the given directory.
@@ -234,6 +231,17 @@ in the given directory.
If the given parametter is a file (or a symlink to a file), it will terminate
with an error.
#### 4.1.5. patch_file \<source\> \<destination\> [VAR1 [VAR2 ...]]
That function will patch the given file using our priority system, patch it
then place the result in the given destination. The patching will be done when
any @VAR@ item in the source file will match an environment variable of the
exact same name without the trailing @. Variables will be either the
given list or, if nothing is given in parameter, in the global system
variables, in the context of the *init.sh* execution.
Source file must exists and not be empty. The function returns nothing
useful.
### 4.2. Other functionnalities
That file don't profide any other things that the previously listed functions.
@@ -259,9 +267,17 @@ That function takes no parameters and any given parameters will be ignored.
That function installs using the package manager the packages given in
parameters. The list of parameters are all considered as package names.
Before installation the list of package to be installed by the package
manager will be extracted to allow execution of pre installation scripts
and post installation scripts after, even for dependencies.
Preinstallation scripts have to be named *preinst_\<package_name\>*. Post
installation script will be in the form *postinst_\<package_name\>*.
If the *INSTALL_MODE* variable is set to "dev" the package manger will be
called one package after the other. Elsewhere, it will be called once with
the entire package list as parameter.
called surrounded by eventual pre and post install scripts, one package
after the other. Elsewhere, it will be called once with the entire package
list as parameter.
The function depends on the *COM_INSTALL* variable wich define the parameter
to use to accomplish that function.
@@ -348,9 +364,6 @@ Stop the services given in parmeters. You can give as many services you want.
That function relies on the previously documented exec_serv function.
### 6.3. Other functionnalities
That file don't profide any other thing that the previously listed functions.
## 7. The support.sh file
### 7.1. Functions
#### 7.1.1. disp_help
@@ -382,9 +395,21 @@ line.
That function takes no parameters and only change *http_proxy* and *https_proxy*
standard POSIX variables. No usefull result will be returned.
## 8. The version.sh file
## 8. The utils.sh file
### 8.1. Functions
#### 8.1.1. get_os_version
#### 8.1.1. stdtime
Display date and time based on RFC 3339 standard but slightly modified so it can
be used in filename. Thus spaces are replaced by dash, and comas between hours,
minutes and seconds are removed.
That function takes no parameters and return its result on standard output.
### 8.2. Other functionnalities
That file don't profide any other thing that the previously listed functions.
## 9. The version.sh file
### 9.1. Functions
#### 9.1.1. get_os_version
That function takes no parameters and will return three values in order:
1. Distribution ID, in lowcase, usually equivalent to the distribution name.
2. Distribution version, if available, elsewhere kernel version with it's major.
@@ -398,7 +423,7 @@ the [official documentation](https://www.freedesktop.org/software/systemd/man/os
In "*/etc/os-release*" the variables *ID*, *VERSION_ID* and *VERSION_CODENAME*
will be the ones being analysed. Only the *ID* variable is mandatory.
#### 8.1.2. set_sys_var \<arch\> \<dist\> \<version\> \<codename\>
#### 9.1.2. set_sys_var \<arch\> \<dist\> \<version\> \<codename\>
That function sets important variable that will store the system architecture.
It will allow the automatic loading of mandatory system dependent code and
variables. For debugging purpose it will be possible to call it manually.