Dietpi: PREP | dietpi-globals returns exit code 1

[Fourdee]

root@pinebook1080p:/tmp# . ./dietpi-globals ;echo $?
1
root@pinebook1080p:/tmp# . ./dietpi-globals ;echo $?^C
root@pinebook1080p:/tmp# G_AG
G_AGA                      G_AGP
G_AGDUG                    G_AGUG
G_AGF                      G_AGUP
G_AGI                      G_AG_CHECK_INSTALL_PREREQ

[Fourdee]

shellcheck: unable to decommit memory: Invalid argument

[Fourdee]

13th Nov commit is fine:
https://github.com/Fourdee/DietPi/commit/48017eb6dbd626d19f92e581b460331d03aa6d6a#diff-03a4faa1a3aeff0af60938482f5791b3

And fine:
https://github.com/Fourdee/DietPi/blob/41f3854f30e19c46cd5111617ea718211193a592/dietpi/func/dietpi-globals

---

Fails:
https://github.com/Fourdee/DietPi/blob/beff8ec96efa2d3d19ce568f258a69ea1d5cb3f7/dietpi/func/dietpi-globals

---

Issue is with commits on 20th:
https://github.com/Fourdee/DietPi/commits/dev/dietpi/func/dietpi-globals

---

Cause:
https://github.com/Fourdee/DietPi/commit/471d0b5295133ea66c660403538278987b179159#diff-03a4faa1a3aeff0af60938482f5791b3R2525

[[ $G_DEBUG == 1 ]] && G_DIETPI-NOTIFY 2 'DietPi-Globals loaded\n'

[Fourdee]

Interesting:

• 🈯️ exit code 0

    if (( $G_DEBUG == 1 )); then

        G_DIETPI-NOTIFY 2 'DietPi-Globals loaded\n'

    fi

• 🈴 exit code 1

(( $G_DEBUG == 1 )) && G_DIETPI-NOTIFY 2 'DietPi-Globals loaded'

[MichaIng]

@Fourdee
Hmm, just re-comment the line or remove. Strange though.

I would not do (( $G_DEBUG )) as this would require it to be always defined. Would like to have as few as possible variable definitions required, which means to check via [[ ]] in most cases to allow var being unset.

Especially in terminal would be great to allow as much unset as possible.

€: How did you check? Didn't know sourcing something can have an exit code 🤔.

[MichaIng]

@Fourdee
Ah lol my last thoughts lead me to the right point:

2018-11-22 00:21:41 root@micha:/tmp# [[ $G_DEBUG ]] && :; echo $?
1
2018-11-22 00:21:45 root@micha:/tmp# [[ $G_DEBUG ]] && :; echo $?
1
2018-11-22 00:21:47 root@micha:/tmp# [[ ! $G_DEBUG ]] && :; echo $?
0

This is no exit code of the script, it is just the "result" of the check 😄. So totally expected.
As I though, sourcing scripts do not have an exit code, but in case just the result of the last command or check.

... ah, this also means we cannot check, if sourcing went fine or not, or at least it would require a true at the end:

2018-11-22 00:24:34 root@micha:/tmp# true; echo $?
0
2018-11-22 00:24:38 root@micha:/tmp# false; echo $?
1

• At least by this we can check if the sourcing reached end of script.... But obsolete check actually.. if it wouldn't, I guess "parent" script wouldn't go on as well.

---

if-then-fi loop seems to unset the exit code of the condition check:

2018-11-22 00:29:17 root@micha:/tmp# (( 0 == 1 )); echo $?
1
2018-11-22 00:29:33 root@micha:/tmp# (( 0 == 0 )); echo $?
0
2018-11-22 00:29:37 root@micha:/tmp# if (( 0 == 0 )); then :; fi; echo $?
0
2018-11-22 00:29:54 root@micha:/tmp# if (( 1 == 0 )); then :; fi; echo $?
0

[Fourdee]

@MichaIng

ah, this also means we cannot check, if sourcing went fine or not, or at least it would require a true at the end:

Should be fine as script is in memory, any syntax errors will display during load, even if a function is not used yet.

We could just return 0 at end of globals to resolve I believe.

[MichaIng]

@Fourdee

Should be fine as script is in memory, any syntax errors will display during load, even if a function is not used yet.

Ah jep forgot 👍.

~return is only allowed in functions~
€: Ah lol or sourced script, great 😄.

2018-11-22 00:33:37 root@micha:/tmp# false; true; echo $?
0
2018-11-22 00:34:04 root@micha:/tmp# false; echo $?
1
2018-11-22 00:34:08 root@micha:/tmp# true; echo $?
0

true works (€: as well) and does overwrite any previous exit code.

[Fourdee]

@MichaIng

    (( $G_DEBUG == 1 )) && G_DIETPI-NOTIFY 2 'DietPi-Globals loaded\n'
    return 0

root@DietPi:~# . /DietPi/dietpi/func/dietpi-globals; echo $?
0

[MichaIng]

@Fourdee
Okay, then revert to [[ $G_DEBUG == 1 ]] check to allow this being unset?

[Fourdee]

@MichaIng

Fixed with commit https://github.com/Fourdee/DietPi/commit/54477861aa20dfa41550e50885c39fe92d2b0335

Trigger last command as null, which always returns exit code 0

ref: https://unix.stackexchange.com/questions/118217/chmod-silent-mode-how-force-exit-code-0-in-spite-of-error

[MichaIng]

Btw:
Yesterday night I finally read about the biggest benefit of wrapping whole scripts into { ... }.
I was always a bid sceptic, since most of our scripts are in memory (tmpfs) anyway and pre-parsing the whole script takes more init time.

• Scripts not being pre-parsed can be parsed partially, e.g. functions only, if they are actually called. E.g. would speed up set_software/hardware scripts where largest parts are not needed for most calls.
• But, besides syntax errors showing up directly, also if a script is called without { } and the code is somehow changed, the changed code will be parsed within the same call. So e.g. during dietpi-update, if the update script is updated, afterwards the new code is parsed directly. If we changed variables or stuff, this must fail then 😄.
• So stay with { } is definitely the safer way!

---

Ah the reason I remember this:

• Manual exit call is important then to not let the shell parser looking for follow-up code outside of }. And I guess in case of dietpi-globals, return has the same effect here 👍.
  €: Ah okay now you use :

2018-11-22 00:39:54 root@micha:/tmp# false; :; echo $?
0

• Yeah works as well, didn't know that. It's definitely the fastest dummy command I could find.

[MichaIng]

2018-11-22 00:55:21 root@micha:/tmp# cat test
#!/bin/bash

echo 1
echo -e 'echo 2\necho 3\necho '\''echo 4'\'' >> test' >> test
2018-11-22 00:55:23 root@micha:/tmp# ./test
1
2
3
4
2018-11-22 00:55:32 root@micha:/tmp# cat test
#!/bin/bash

echo 1
echo -e 'echo 2\necho 3\necho '\''echo 4'\'' >> test' >> test
echo 2
echo 3
echo 'echo 4' >> test
echo 4

😆

[Fourdee]

@MichaIng

So e.g. during dietpi-update, if the update script is updated, afterwards the new code is parsed directly. If we changed variables or stuff, this must fail then 😄.

Yep, one of the main reasons for doing the {}. The other was to load into memory before we had a DietPi-RAMdisk (years ago).

But the benefit of loading the script as it is, into memory without a chance of in-runtime change is a must. Also the ability to report any syntax errors in the whole script during load is hugely beneficial for our side.

[Fourdee]

Ok, lets mark this as completed.