Not a bug, but a suggestion to make detecting invalid debconf inputs easier.

We just had a case where grub-efi-amd64's postinst script always failed
without any error message. Debugging the shell script with "set -x"
revealed, that "exec /usr/share/debconf/frontend ..." was reached before
the exit. Debugging that perl script was tedious, given that only
"perl-base" was installed (not perl debugging modules), so "perl -d" did
not work without satisfying dpkg by moving "postinst" out of the way, to
allow installing perl modules.

Perl debug output from the "/usr/share/debconf/frontend" call is huge,
detecting errors difficult. We saw that it exits after
```
1 while ($confmodule->communicate)
```

Adding "set -x" to the package's "config" shell script gave these last
commands

```
+ RET=30 question skipped
+ local _db_status=30
+ return 30
```

which is a normal exit for non-interactive configuration. It took a
while before we recognised the unusual return code some input values
earlier, after "db_input medium grub2/linux_cmdline":

```
+ RET=20 Bad line "" received from confmodule.
+ local _db_status=20
+ return 20
```

But where this bad line was coming from remained unclear, also when "set
-x" debugging the "config" shell script.

It took another while before we recognised the empty line in the debug
output

```
+ IFS=
+ printf %s\n SET grub2/linux_cmdline_default foo bar

+ IFS=
```

as well as from the "source /etc/default/grub", between two assigned
variables:

```
+ GRUB_CMDLINE_LINUX_DEFAULT=foo bar

+ GRUB_CMDLINE_LINUX=net.ifnames=0
```

As can be seen, the faulty value was not in
"grub2/linux_cmdline"/"GRUB_CMDLINE_LINUX", but in
"grub2/linux_cmdline_default"/"GRUB_CMDLINE_LINUX_DEFAULT" processed before.

When editing "GRUB_CMDLINE_LINUX_DEFAULT", the user accidentally added a
newline before the closing double-quote character. This newline was
hence part of the "GRUB_CMDLINE_LINUX_DEFAULT" value. debconf's frontend
script however expects a single line per input, and the newline
character caused it to receive and fail on a separate empty line, when
retrieving the input for the next config key.

Also interesting is, that an interactive "dpkg-reconfigure" failed as
well. So even retrieving a valid value from whiptail output, did not
prevent the failure. Or maybe the newline character was overlooked in
the whiptail inputbox, not sure whether whiptail inputboxes can
theoretically take control characters as default value, and return them
as well.

It would really help if debconf could print meaningful error messages,
when receiving invalid inputs. Debugging these nested shell => perl =>
shell calls with the way how the debconf frontend script calls an
retrieves output from the "config" shell script, is not trivial, also
since the "config" script cannot exit in place due to required "db_input
... || true", so that the actual error in its debug output can be buried.

Best regards,

Micha