#3151 Issue closed: SLES15 SP5: vi: E1187: Failed to source defaults.vim¶
Labels: enhancement, cleanup, fixed / solved / done,
minor bug
abbbi opened issue at 2024-02-12 07:22:¶
hi,
this is an minor issue as it does not affect functionality but can be fixed quite easily:
Executing "vi" within the bootet recovery iso (sles15 sp5) shields the following error:
E1187: Failed to source defaults.vim
Press ENTER or type command to continue
workaround is to create an empty /root/.vimrc file.
abbbi commented at 2024-02-12 10:50:¶
would
https://github.com/rear/rear/blob/master/usr/share/rear/build/GNU/Linux/130_create_dotfiles.sh
be the right place to simply touch the file?
pcahyna commented at 2024-02-13 10:15:¶
I suppose this would work, but I suspect https://github.com/rear/rear/tree/master/usr/share/rear/skel/default/root would be an even better place, as the file is static and if you put it there, you will see just by looking at the directory listing that it is there, instead of having to look inside the code and think about what it is doing.
abbbi commented at 2024-02-13 11:08:¶
I suppose this would work, but I suspect https://github.com/rear/rear/tree/master/usr/share/rear/skel/default/root would be an even better place, as the file is static and if you put it there, you will see just by looking at the directory listing that it is there, instead of having to look inside the code and think about what it is doing.
if the user wants to ship its custom .vimrc file that might be the
better place.. yes. But by default? Touching it ifs existant
during dotfiles creation doesnt hurt anyone and would create it if not.
pcahyna commented at 2024-02-13 13:31:¶
I don't say it will hurt, but having a static file in the directory structure is easier to understand for developers who sometimes need to check how something happens (I am among them), than having a code to generate it dynamically.
jsmeix commented at 2024-02-13 13:34:¶
I can reproduce it.
I will have a look how to solve it properly.
jsmeix commented at 2024-02-13 13:39:¶
Offhandedly I think that
dynamically generating something static
is (or at least looks) self-contradicting.
The current static
nano /var/lib/rear/layout/diskrestore.sh # disk restore
nano /var/lib/rear/layout/disklayout.conf # disk layout
in usr/share/rear/build/GNU/Linux/130_create_dotfiles.sh
is not fully correct because there is not always 'nano'
in the ReaR recovery system so that .bash_history lines
should be dynamically generated depending on whether
or not 'nano' is in the ReaR recovery system.
Probably the same is true for the current static
vi /var/lib/rear/layout/diskrestore.sh # disk restore
vi /var/lib/rear/layout/disklayout.conf # disk layout
because I vaguely remember there are systems without 'vi'
which use 'nano' as basic text editor - perhaps Ubuntu?
pcahyna commented at 2024-02-13 13:51:¶
I would keep dynamic generation of (currently) static .bash_history
there though because I hope that we would eventually make it dynamic.
For example, it does not make much sense to preload nano into history
if there is no nano in the rescue image. But this issue does not have
a high priority for me :-)
edit: jinx!
[Export of Github issue for rear/rear.]