#2622 Issue closed: UserInput: Backspace does not erase characters¶

Labels: fixed / solved / done, minor bug

OliverO2 opened issue at 2021-06-02 14:17:¶

When using rear recover via ssh in an xterm window with disk remapping, this is what is looks like when Backspace is pressed, trying to erase the 1:

Choose an appropriate replacement for /dev/sda
1) /dev/vda
2) /dev/vdb
3) /dev/vdc
4) Do not map /dev/sda
5) Use Relax-and-Recover shell and return back to here
(default '1' timeout 300 seconds)
1^?

After the digit 1, an escape sequence for the delete character ^? appears, making the input invalid.

The cause is the -n 1000 option used for the read invocation by UserInput by default. To reproduce, use the following invocation, then type 1 followed by the Backspace key:

$ read -t 300 -n 1000 x; echo "Input: <$x>" | cat -v
1^?
Input: <1^?>

Removing -n makes everything work.

The bash manual page on read says:

-n nchars

read returns after reading nchars characters rather than waiting for a
complete line of input, but honors a delimiter if fewer than nchars
characters are read before the delimiter.

So nchars is not really useful to limit the input line length, but to allow for single-character input without requiring a Return key press.

USER_INPUT_MAX_CHARS is implemented as described, but not used anywhere in ReaR.

jsmeix commented at 2021-07-15 07:20:¶

The intent of USER_INPUT_MAX_CHARS is not to limit the input line length by default
so the default USER_INPUT_MAX_CHARS=1000 is intentionally so big
to allow in practice unlimited input line length.

But read -n 1000 has the bad (and undocumented as far as I can see) side effect
to make correcting/editing the input (before the Return key is pressed) impossible.

So I have to change things to avoid that unintended and bad side effect.

jsmeix commented at 2021-07-15 07:28:¶

Oh!
It seems (at least for me with GNU bash version 4.4.23 on openSUSE Leap 15.2)
read behaves with -n 0 same as if no -n ... option was specified so sinply
USER_INPUT_MAX_CHARS=0 in default.conf should do it.
But I have to test if read -n 0 behaves well also with older bash.

jsmeix commented at 2021-07-15 08:17:¶

Things work well for me with https://github.com/rear/rear/pull/2658

@OliverO2
thank you for the issue report and in particular
many thanks for your analysis what the root cause was that
made correcting the input (before [Enter] is pressed) impossible.

jsmeix commented at 2021-07-16 10:29:¶

With https://github.com/rear/rear/pull/2658 merged
this issue should be fixed.

---

[Export of Github issue for rear/rear.]