DietPi-Update | G_ERROR_HANDLER does not exit script on error

[MichaIng]

On e.g. G_AGUP or G_AGUG error or some download error or similar, dietpi-update continues instead of exiting.

Investigating the issue, I recognised that kill -INT $$ runs with correct argument (dietpi-update script PID), but is simply ignored. Some test shows that this is always the case when piping the output of a function and trying to kill the script from within the function:

root@DietPi:/tmp# cat test
#!/bin/bash
func(){
        echo started func $$
        kill -INT $$
        echo failed to kill func $$
}
echo started script $$
func | tee
echo failed to kill script $$
root@DietPi:/tmp# ./test
started script 3001
started func 3001
failed to kill func 3001
failed to kill script 3001

Some search about this: https://stackoverflow.com/questions/45303270/bash-redirect-vs-pipe

• But in this mention case, the kill attempt is done from within the pipe target, where it makes sense to me, but in our case the kill attempt is done from within the pipe origin.

Redirection, even of both streams, does not have this issue:

root@DietPi:/tmp# cat test
#!/bin/bash
func(){
        echo started func $$
        kill -INT $$
        echo failed to kill func $$
}
echo started script $$
func &> >(tee)
echo failed to kill script $$
root@DietPi:/tmp# ./test
started script 3006

root@DietPi:/tmp# started func 3006

But not only the syntax looks a bid ugly, but also the output shows that the originating script does not wait for the subshell to finish:

root@DietPi:/tmp# echo 1 &> >(tee); echo 2
2
root@DietPi:/tmp# 1

This can be worked around with a wait:

root@DietPi:/tmp# echo 1 &> >(tee); wait $!; echo 2
1
2

While running tests I was first surprised that redirection to subshell seems to be MUCH faster then piping:

root@VM-Stretch:~# time for i in {1..1000}; do printf '' 2>&1 | tee; done

real    0m2.934s
user    0m0.048s
sys     0m0.564s
root@VM-Stretch:~# time for i in {1..1000}; do printf '' &> >(tee); done

real    0m1.029s
user    0m0.132s
sys     0m0.576s

However this is indeed only due to loop not waiting for tee:

root@VM-Stretch:~# time for i in {1..1000}; do printf '' &> >(tee); wait $!; done

real    0m2.998s
user    0m0.096s
sys     0m0.428s

And suddenly we are VERY close to the speed of piping 😉.

The bug is a regression from v6.25: 4285af6#diff-c613a85da508fb885b67c34f9661e243
Currently I see no chance then restoring the bid uncommon redirection of pre-v6.25. Seems like @Fourdee had some good reason to implement it like this and we need to keep this in mind whenever piping an error handled functions output.

[MichaIng]

Fixed with: 1e52d13
Changelog: a3c8cf0