DietPi-Globals | Add new error handled command wrapper G_EXEC

[MichaIng]

Status: Ready

Commit list/description:

• DietPi-Globals | Add new error handled command wrapper G_EXEC which combines G_RUN_CMD and G_ERROR_HANDLER. Output redirects can be done via "eval".

[MichaIng]

Hmm strange issue:

ownCloud install:

...
G_EXEC_DESC='ownCloud occ install'
# - Replace password string internally to avoid printing it to console
G_EXEC_PRE_FUNC(){ acommand[10]=$GLOBAL_PW acommand[14]=$GLOBAL_PW; }
# - Checking output for stack trace to handle internal errors that do not lead to php error exit code
G_EXEC_POST_FUNC(){ grep -qi 'Stack trace' $fp_log && exit_code=1337; }
G_EXEC occ maintenance:install --no-interaction --database 'mysql' --database-name 'owncloud' --database-user 'tmp_root' --database-pass '<omitted>' --admin-user "$username" --admin-pass '<omitted>' --data-dir "$datadir" | tee fp_output
...
G_EXEC systemctl restart redis-server

Output:

[  OK  ] DietPi-Software | ownCloud occ install
...
[FAILED] DietPi-Software | ownCloud occ install
 - Command: systemctl restart redis-server

The error prompt reveals that the command array contains an entry dietpi, as added by G_EXEC_PRE_FUNC above (default password), the mismatch between "[FAILED]" print and actual command name below shows that G_EXEC_DESC and G_EXEC_PRE_FUNC were not unset.
This is very strange since this is explicitly done at the end of G_EXEC, there is no path around this, and the very same case with Nextcloud install works without this issue. Also the next G_EXEC calls during ownCloud install have the variables unset.
I made a lot of tests in console and couldn't find any way how the variable and the function are able to survive the G_EXEC call. Also the very same construction worked for with G_ERROR_HANDLER and it works well with G_EXEC in all other cases. What is different with the ownCloud install?

---

🈴 Simple unset two times does not help

---

🈯️ Found it, there was an obsolete tee pipe in place which was a prior attempt to handle occ command stack trace errors, before G_EXEC_POST_FUNC was implemented. The problem with pipes is, that pipe input functions (left side of |) loose any possibility to affect the originating shell environment, e.g. cannot unset variables of functions anymore and also cannot kill the originating shell. The same was the reason for (already present with G_ERROR_HANDLER:

# - Log to file by redirecting to subshell instead of piping, else G_EXEC cannot exit the script via "kill -INT $$": https://github.com/MichaIng/DietPi/issues/3127
Run_Update &> >(tee $FP_LOG_TMP); wait $!

Final important result: G_EXEC must never be piped. G_EXEC_POST_FUNC was the required implementation to handle errors, visible in output without producing an error exit code.