You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it could be better when instead of an uninterruptible 'sleep'
an interruptible 'read' call is used so that the user could in particular
interrupt longer sleep delays.
E.g. for longer sleep delays something like this:
delay=10
Print "sleeping $delay seconds, hit any key to interrupt"
read -t $delay -n 1 -s 0<&6 && Print "sleep interrupted"
That code sleeps silenty unless ReaR runs in verbose mode.
A possible drawback is that "rear recover" always runs verbose
so that during "rear recover" the user gets unexpected messages
about those sleep delays but on the other hand it is the intent
that the user can interrupt those sleeps.
This issue is somewhat related to the basic ideas behind #1366
and #1399
that both intend to give more power to the user.
This issue here intends to empower the user to
interrupt longer sleep delays.
The text was updated successfully, but these errors were encountered:
What should happen if a user interrupts the sleep? Should ReaR continue like nothing happened or should ReaR abort?
If to change something then I would only improve the exit behavior of ReaR, meaning that ReaR would faster or cleaner abort when the user presses Ctrl-C. Otherwise I assume that all the sleeps in ReaR are there for a very good reason.
If you think that a sleep is not needed then please simply remove it instead of creating a workaround.
A plain 'sleep' is basically never there for a good reason.
A plain 'sleep' basically always tells that
the one who made the code had no idea
what the actual thing is that should be waited for
so that he used 'sleep $blind_guess_delay_time'
as some kind of workaround.
In current ReaR code there are several 'sleep' calls
with various sleep delay times
(first column shows how often each is used):
I think it could be better when instead of an uninterruptible 'sleep'
an interruptible 'read' call is used so that the user could in particular
interrupt longer sleep delays.
E.g. for longer sleep delays something like this:
That code sleeps silenty unless ReaR runs in verbose mode.
A possible drawback is that "rear recover" always runs verbose
so that during "rear recover" the user gets unexpected messages
about those sleep delays but on the other hand it is the intent
that the user can interrupt those sleeps.
This issue is somewhat related to the basic ideas behind
#1366
and
#1399
that both intend to give more power to the user.
This issue here intends to empower the user to
interrupt longer sleep delays.
The text was updated successfully, but these errors were encountered: