Cursor and Tab keys produce control characters when setting up pi-hole

Sorry for the late reply. So the issue only appears if you select Pi-hole to be installed on first boot, but not when calling dietpi-software manually afterwards?

Now I can imagine the issue/difference. From first login script we call dietpi-software like this, to create a log of the first run setup:

/boot/dietpi/dietpi-software 2>&1 | tee -a "$FP_DIETPI_FIRSTRUNSETUP_LOG"

So it redirects STDOUT and STDERR into tee, which splits the output into the log file and onto screen. whiptail does not seem to have issues with this, but dialog does show the exact behavior you describe:

whiptail --yesno test 20 80 2>&1 | tee
dialog --yesno test 20 80 2>&1 | tee

There is another approach to redirect all output into tee which does not make use of a pipe, but it does not work either:

dialog --yesno test 20 80 &> >(tee)

So dialog requires either STDOUT or STDERR to remain on the original console directly, which makes it incompatible with proper logging of the surrounding script output. Maybe there is a way to redirect STDOUT for the dialog call only to the parent console. I mean it does not create any readable log lines anyway. But this makes it even worse: it exits on first key press:

bash -c 'dialog --yesno test 20 80 > "/proc/$PPID/fd/1"' 2>&1 | tee

EDIT: Now the above thing suddenly works. Ehm okay, no idea what went wrong before, maybe I fucked up that shell setup with prior tests. $PPID is the process ID of the parent process, so it takes its STDOUT, bypassing the tee pipe for this particular dialog call in the script. But it would be difficult to hack that into the Pi-hole installer. Maybe with a shell function:

bash -c 'dialog(){ /usr/bin/dialog "$@" > "/proc/$PPID/fd/1"; }; dialog --yesno "dialog call 1" 20 80; dialog --yesno "dialog call 2" 20 80' 2>&1 | tee

This works for me. So we could hack this function to the first line of the Pi-hole installer script, using the $PPID value from the dietpi-software shell, which is the dietpi-login shell that does not have its output redirected. Condition for this could be

read -r parent_process < "/proc/$PPID/comm"
if [[ $parent_process == 'dietpi-login' ]]
...

EDIT2: Let’s test whether this works:

Okay, it does work. Since the Pi-hole installer itself sometimes masks STDOUT by catching its output within a command substitution, we need to redirect both STDOUT and STDERR, to assure there is always at least one stream still attached to the parent terminal.

This might even be a good idea for whiptal calls, to keep the log free of cryptic characters from navigating through the menus.