#2866 Issue `closed`: Hitting ENTER too often lets subsequent "rear recover" user dialogs proceed unintendedly¶

Labels: enhancement, fixed / solved / done, minor bug

jsmeix opened issue at 2022-09-21 13:17:¶

During "rear recover" there can be several user dialogs
(in particular when MIGRATION_MODE is 'true').

When one accidentally hits ENTER more than once in one dialog
the first one is consumed from stdin to proceed that one dialog
but the other ENTER(s) stay in stdin so a subsequent dialog
has already ENTER in stdin which makes the subsequent dialog
proceed unintendedly automatically without an explicit ENTER
from the user for this current dialog.

My offhanded idea is to let the UserInput function
in lib/_input-output-functions.sh
drain stdin either at its beginning when it is called
or at its end yet before it returns to its caller.
Because the UserInput function has several return calls
I would prefer the first method (drain stdin at its beginning).

jsmeix commented at 2022-09-22 11:09:¶

It must be the first method
(drain stdin at UserInput function beginning)
because the user may unintendedly type something
after a UserInput function had finished
so this new typed thing will appear in stdin
when the next UserInput function is called.

It must not be done when ReaR is not run interactively
e.g. when ReaR is run with redirected stdin from a pipe,
cf. "It should be possible to run ReaR unattended" in
https://github.com/rear/rear/wiki/Coding-Style

So drain stdin at UserInput function beginning
must be only done when tty -s results zero exit code, cf.
https://www.gnu.org/software/coreutils/manual/html_node/tty-invocation.html#tty-invocation

Regarding "drain stdin bash" Google found
https://superuser.com/questions/276531/clear-stdin-before-reading

jsmeix commented at 2022-09-22 11:44:¶

Testing backward compatibility of

read -s -t0.1 -n 10000 drain_stdin

On SLES10 SP4:

# read -s -t0.1 -n 10000 drain_stdin
-bash: read: 0.1: invalid timeout specification

# bash --version
GNU bash, version 3.1.17(1)-release (x86_64-suse-linux)

# read -s -t1 -n 10000 drain_stdin
[works]

On SLES11 SP4:

# read -s -t0.1 -n 10000 drain_stdin
-bash: read: 0.1: invalid timeout specification

# bash --version
GNU bash, version 3.2.57(1)-release (x86_64-suse-linux-gnu)

# read -s -t1 -n 10000 drain_stdin
[works]

On SLES12 SP5:

# read -s -t0.1 -n 10000 drain_stdin
[works]

# bash --version
GNU bash, version 4.3.48(1)-release (x86_64-suse-linux-gnu)

So it seems that read timeout can be a fractional number
requires bash 4.x but in general ReaR should still work
with bash 3.x so I will use

read -s -t1 -n 10000 drain_stdin

which causes a one second delay at the beginning
of each UserInput function call when ReaR is run
interactively.

I think I cannot mitigate the one second delay e.g.
by calling read -s -t1 -n 10000 drain_stdin
after the UserInput function has shown its request output
message (because the user needs some time to read it anyway)
where it asks for user input because at this point in time
the UserInput function must accept user input and not
discard any (because the user may expect that request
for user input and hit the ENTER key to proceed immediately
after the UserInput function has shown its request output
message).

I tested it and for me the one second delay
is hardly noticeable in interactive mode
so I think it is acceptable.

pcahyna commented at 2022-09-23 09:38:¶

Do we still need to support bash 3, in light of https://github.com/rear/rear/issues/2820#issuecomment-1162919836 ? Or is it for easier backporting of the change to ReaR versions that you want to support SLES11 ?

jsmeix commented at 2022-09-23 09:54:¶

As long as we ReaR upstream maintainers did not
all together decide to drop support for bash 3.x
I will keep support for bash 3.x
as good as possible with reasonable effort.

Over time more and more bash 4.x only code will creap in
because we cannot verify all contributions (including
our own contributions) regarding bash 3.x compatibility
so over time we will reach a state where ReaR
does no longer work in practice with bash 3.x.

Should I open a new RFC issue to officially
declare bash 3.x support as deprecated or unmaintained
or to even officially drop bash 3.x support in ReaR?

jsmeix commented at 2022-09-28 13:19:¶

With https://github.com/rear/rear/pull/2868 merged
this issue should be (hopefully) sufficiently solved.

[Export of Github issue for rear/rear.]

#2866 Issue closed: Hitting ENTER too often lets subsequent "rear recover" user dialogs proceed unintendedly¶