#3072 PR merged: Add USER_INPUT_UNATTENDED_TIMEOUT config variable

Labels: enhancement, fixed / solved / done

jsmeix opened issue at 2023-11-09 09:37:

  • Type: Enhancement

  • Impact: Low

  • Reference to related issue (URL):

While testing
I noticed that UserInput() timeout is 3 seconds
but I had no idea where that came from
(default UserInput() timeout is 300 or 30 seconds)
until I found out that in unattended recovery mode
calls rear --non-interactive recover
and in non-interactive mode UserInput() does

# set timeouts to low but acceptable 3 seconds for non-interactive mode:

with a hardcoded '3' that I could not find easily
in the whole ReaR code (without knowing where to look for).
I think having it hardcoded is wrong because for example
why should UserInput() wait at all when there is no user
who could see any input request or ever respond to it
so it should be possible to set it to 1 if needed
(e.g. for 'unattended' recovery).
A timeout of 0 would get complicated to be implemented because
'read -t 0' returns immediately without trying to read any data
so it seems when 'read' should time out the minimum is '1',
cf. the "Drain stdin" comment in the UserInput function:

# That the 'read' timeout can be a fractional number requires bash 4.x
# see https://github.com/rear/rear/issues/2866#issuecomment-1254908270
# but in general ReaR should still work with bash 3.x so we use '-t 1'

and I think a 'read' timeout fractional number is not a sufficient
reason to require bash 4.x mandatorily for the UserInput function.

  • How was this pull request tested?

Works well for me so far...

  • Description of the changes in this pull request:

to specify the timeout in seconds (by default 3)
for how long UserInput() waits for user input
when ReaR is run in 'unattended' or 'non-interactive' mode.

jsmeix commented at 2023-11-10 07:46:

provided there are no objections
I would like to merge this soon

schlomo commented at 2023-11-10 10:33:

@jsmeix side note: Didn't we recently determine that all actively supported distros use Bash 4.x nowadays?

jsmeix commented at 2023-11-10 12:29:

yes, all actively ReaR upstream supported distros use Bash 4.x
but in general I do not like to "just break" backward compatibility
unless there is a reasonable reason for it.

In this particular case support for fractional numbers
for the 'read' timeout values would require several
other code changes because


# test "$USER_INPUT_INTERRUPT_TIMEOUT" -ge 1 && echo OK


# test "$USER_INPUT_INTERRUPT_TIMEOUT" -ge 1 && echo OK
bash: test: 1.1: integer expression expected

Currently I think this is not worth the effort, cf.

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

schlomo commented at 2023-11-10 12:34:

@jsmeix I agree with your reasoning about this particular case, I'd just like to remove the "must work with Bash 3.x" from our minds.

I find it totally fine if Bash 3.x distros will be locked into ReaR 2.7.

jsmeix commented at 2023-11-10 12:45:

I fully agree with your

jsmeix commented at 2023-11-10 13:31:

I edited
so that it reads now


Relax-and-Recover is written in Bash (Bash version 4 is needed)

and in the section "Maintain backward compatibility" the part

In particular avoid special bash version 4 features
(Relax-and-Recover code should also work with bash version 3).

is now removed, see

I see now that openSUSE Factory / Tumbleweed has bash-5.2.tar.gz
but I don't know how far Bash 5 is backward compatible with Bash 4
so for now I leave the statement "Bash version 4 is needed" as is
and leave it to Bash 5 users to test and find out on their own
what that means for their particular ReaR use cases.
Cf. what I wrote about openSUSE Tumbleweed in our release notes:

In theory ReaR 2.7 should work on openSUSE Tumbleweed but in practice
arbitrary failures could happen at any time because the Tumbleweed
distribution is a pure rolling release version of openSUSE containing the
latest stable versions of all software
(cf. https://en.opensuse.org/Portal:Tumbleweed) so arbitrary changes of any
software are possible at any time that could arbitrarily break how ReaR works.


FYI: SLE15 has Bash version 4.4

jsmeix commented at 2023-11-10 13:52:

@schlomo @pcahyna
thank you for your prompt review!

schlomo commented at 2023-11-12 18:55:

Thanks for updating the docs, good thinking!

[Export of Github issue for rear/rear.]