Mkrescue: use the text editor that is available (vi: command not found)

[ProBackup-nl]

• 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.):

1. vi
2. pico
3. nano

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]

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 #892

[ProBackup-nl]

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]

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]

Hi all!

If I can vote for a default editor I will vote for vi ;-P

Regards,

[jsmeix]

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 #892
and #1233

[gdha]

@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]

@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]

@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]

On the one hand I agree with @schlomo
#1298 (comment)
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]

@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]

As /bin/nano is already part of PROGS array so we can close this case.

[jsmeix]

@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.