#1298 Issue closed: Mkrescue: use the text editor that is available (vi: command not found)¶
Labels: enhancement, cleanup, fixed / solved / done
ProBackup-nl opened issue at 2017-04-14 14:39:¶
- rear version (/usr/sbin/rear -V): 2.00 git
- OS version (cat /etc/rear/os.conf or lsb_release -a): Arch rolling
- Are you using legacy BIOS or UEFI boot? UEFI
- Brief description of the issue: vi not available on host results in
/usr/share/rear/layout/prepare/default/500_confirm_layout.sh:
line 22: vi: command not found.
Linux.conf contains at least 3 different editors in the PROGS array (to copy to the recovery env.):
Don't assume that vi is available¶
Image a slim (Arch) Linux installation (not those fat distros RHEL, Ubuntu, etcetera) that comes with no editor. A user has got a preference for a specific text editor, and only installs that text editor only.
No vi installed¶
When that text editor is not vi, then the ReaR recovery environment
version 2.00 will show an error message when trying to edit the disk
layout (for instance).
Check for editor executable existence¶
Check that the editor is actually on the source system, before using that editor in 500_confirm_layout and similar vi dependant scripts
Mkrescue abort when no editor?¶
An additional improvement, might be to abort mkrescue when no (known)
editor is available on the source system.
More then 1 text editor on source?¶
Then try to guess the user favourite text editor?
No clue, then look for configuration option?
Still no clue, then ask the user?
jsmeix commented at 2017-04-18 12:32:¶
As far as I know it does not really matter
when things in PROGS array do not actually exist.
Only for the REQUIRED_PROGS array it should matter
but see
https://github.com/rear/rear/issues/892
ProBackup-nl commented at 2017-04-21 07:53:¶
The issue is not whether any editor is required or not. User experience
will improve when Rear picks the editor that is available instead of
having a hard-coded vi.
schlomo commented at 2017-04-21 13:37:¶
I guess this is a really difficult topic. To be correct we should be
looking at $VISUAL and $EDITOR, however most users set that in their
user environment and not globally (ReaR runs as root and not as a
user). Also, that would mean handling cases like me where
EDITOR=atom -w which obviously won't work in the ReaR rescue system.
So what is the best fall-back option? IMHO we should decide upon one
editor which we always take along, e.g. nano, and also make sure that
is is present via REQUIRED_PROGS and package dependencies. That way we
can guarantee that there will be a functioning editor in the rescue
environment.
To soften that we could go ahead and respect the EDITOR environment
variable and pull that into REQUIRED_PROGS and pray that it won't need
any other files that we are not aware of. Since this seems rather risky
I would prefer deciding upon a standard editor.
didacog commented at 2017-04-21 13:51:¶
Hi all!
If I can vote for a default editor I will vote for vi ;-P
Regards,
jsmeix commented at 2017-04-21 14:11:¶
I think "rear mkrescue" could inspect whatever
is appropriate to find root's preferred editor
but I also think it must be implemented
based on a whitelist of known editors
that are supported by ReaR to avoid
things like "EDITOR=/usr/local/X11/fancyGUIedit"
could make it into the ReaR recovery system.
The final fallback must be 'vi' and if that one
is not available on the source system
"rear mkrescue" must error out (see below).
@didacog
the main issue here is not about what editor to use
by default when several editors are available,
the main issue is to ensure there is at least one editor
available in the recovery system (and use that one).
@ProBackup-nl
I agree to abort mkrescue when no (known) editor is available
on the source system.
In general I think a ReaR rescue/recovery system must contain
an editor even if usually no editor should be actually needed
(usually "rear recover" should "just work") but in general
any rescue system must contain an editor.
Regarding that "rear mkrescue" may not abort when
needed programs for the recovery system are missing,
see above
https://github.com/rear/rear/issues/892
and
https://github.com/rear/rear/issues/1233
gdha commented at 2017-04-21 16:10:¶
@ProBackup-nl To reverse the question: why would you need an editor to recover when the source OS does not have any editor?
We should try to avoid to over-commit ReaR with zillion of pre-condition tests.
jsmeix commented at 2017-04-24 07:57:¶
@gdha
I disagree regarding "pre-condition tests".
I think we should add "zillions of pre-condition tests"
to "rear mkbackup/mkrescue" so that ReaR errors out early
when things are not as expected during "mkbackup/mkrescue"
cf. "Try to care about possible errors" at
https://github.com/rear/rear/wiki/Coding-Style
This way users get known in advance that something
is not as expected by ReaR instead of the current behaviour
where usually "rear mkbackup/mkrescue" succeeds
but later when it is too late for the user to get things
properly fixed (e.g. install needed stuff), "rear recover" fails,
cf. "The user's ultimate expectation: 'rear recover' works" at
https://github.com/rear/rear/wiki/Developers-Guide
Of course there will be a reasonable compromise
between ultimate expectations and feasibility.
gdha commented at 2017-04-24 14:37:¶
@jsmeix if a customized Linux distribution choose to remove an editor - ReaR would be broken if we force an editor. Therefore, I would avoid editors in the REQUIRED PROG array - it is an user option/decision to have an editor on-board (for security reasons). And, as such the user has to make sure DR works with ReaR without intervention required. That is what I meant by adding zillion of pre-condition tests.
jsmeix commented at 2017-05-08 13:21:¶
On the one hand I agree with @schlomo
https://github.com/rear/rear/issues/1298#issuecomment-296192604
that during "rear mkrescue" it should be looking at
the VISUAL and EDITOR environment variables
but on the other hand this probably leads to
an endless sequence of subsequent issues
when VISUAL or EDITOR has "strange" values
like VISUAL=/usr/bin/X11/xemacs
or EDITOR=/usr/bin/X11/oowriter
for particular users ;-)
Therefore it is perhaps best to have another config variable
REAR_EDITOR in default.conf that must default to 'vi'
to keep ReaR working backward compatible regardless
of any VISUAL or EDITOR setting in particular for those
users who have a "strange" VISUAL or EDITOR setting.
When the user sets empty REAR_EDITOR in local.conf
"rear mkrescue" may do whatever sophisticated magic
to autodetect "the right one".
Alternatively the user can specify anything to be used
as editor in the recovery system independent of his
preferred VISUAL or EDITOR setting in his running system
(i.e. "final power to the user" ;-)
E.g. the user may prefer EDITOR=/usr/bin/emacs
in his normal running system but he may also like a small
ReaR recovery system via REAR_EDITOR=/usr/bin/vi
(or whatever fits best for his particular needs).
ProBackup-nl commented at 2017-05-10 20:42:¶
@gdha The case was not that there is no editor at all on the source os. The case is that a different editor then 'vi' is on the original system. My Arch has 'nano' not 'vi'.
gdha commented at 2018-09-19 13:32:¶
As /bin/nano is already part of PROGS array so we can close this
case.
jsmeix commented at 2018-09-20 07:26:¶
@gdha
this enhancement request is that when /usr/bin/vi is not available
but another editor is available e.g. /usr/bin/nano
then all hardcoded places in ReaR that currently call vi
(mainly user dialogs that offer choices to edit files
like disklayout.conf and diskrestore.sh)
would have to be cleaned up and enhanced
to call an actually available editor.
I enhanced the most important user dialogs with the generic choice
Use Relax-and-Recover shell and return back to here
specifically the user dialogs in
/usr/share/rear/layout/prepare/default/300_map_disks.sh
/usr/share/rear/layout/prepare/default/500_confirm_layout_file.sh
/usr/share/rear/layout/prepare/default/200_recreate_hpraid.sh
/usr/share/rear/layout/recreate/default/100_confirm_layout_code.sh
/usr/share/rear/layout/recreate/default/200_run_layout_code.sh
/usr/share/rear/finalize/default/020_confirm_finalize.sh
My personal reason is that when I need to change something
I prefer in general to use the ReaR shell because there
I can do anything I want.
Accordingly in current ReaR the user can already call
whatever editor he likes via using the ReaR shell
so that this enhancement request can be considered
to be already mostly done in practice.
At least I will not have time for further enhancements here
in the foreseeable future so that I set it to "fixed/solved/done"
because I think it works currently sufficiently o.k. in practice
even if it is not yet fully done as requested.
[Export of Github issue for rear/rear.]