Bug 34293

(В ответ на комментарий №0)
> Кстати, необходимость отдельного урезанного vi держится на рассказах о
> мифических авариях, при которых не смонтирован /usr, но посмотрите уже на 
> Fedora, где /bin — это ссылка на /usr/bin.
Если у кого-то руки из жопы (а весь usrmove вызван, помимо прочего, желанием замести под коврик проблемы с линковкой через границу /usr вместо исправления реальных багов) -- вряд ли именно в этом на них стоит ориентироваться.

А применимость vi(1) после неисправимого улучшения vim-minimal (см. bug 33299) и впрямь под большим вопросом, давать такое пользователям как $EDITOR я бы не стал (в отличие от vim).

Улучшение то поправимо, в том то и смех

Правильная программа, которой нужно запустить редактор для редактирования временных файлов, выбирает редактор в следующем порядке:
1. $VISUAL
2. $EDITOR
3. vitmp(1)

Ни vi, ни vim в этом списке нет.
vitmp(1) запускает /bin/vi

(Ответ для Dmitry V. Levin на комментарий #3)
> Правильная программа, которой нужно запустить редактор для редактирования
> временных файлов, выбирает редактор в следующем порядке:
> 1. $VISUAL
> 2. $EDITOR
> 3. vitmp(1)
...
Получается, бага висит не на той компоненте. Тогда нужно переместиться в сторону пакетов или дистрибутивов, задающих эти переменные.

мне, например, больше нравится идея превратить vi в что-то более юзабельное чем есть сейчаc.

(Ответ для Vitaly Lipatov на комментарий #4)
> (Ответ для Dmitry V. Levin на комментарий #3)
> > Правильная программа, которой нужно запустить редактор для редактирования
> > временных файлов, выбирает редактор в следующем порядке:
> > 1. $VISUAL
> > 2. $EDITOR
> > 3. vitmp(1)
> Получается, бага висит не на той компоненте. Тогда нужно переместиться
> в сторону пакетов или дистрибутивов, задающих эти переменные.
Да, VISUAL можно было бы и выставлять (slave alternatives на profiles.d-файл или хотя бы просто "кто встал, того и тапки").

(Ответ для Anton Farygin на комментарий #5)
> мне, например, больше нравится идея превратить vi в что-то более юзабельное
> чем есть сейчаc.
Да, всё-таки "в борьбе за мир" нашим vi(1) в последние годы стало крайне неудобно пользоваться в тех случаях (новый хост/чрут, включая hasher chroot), когда ничего больше по умолчанию не завезли либо вызывается именно /bin/vi в итоге.

2 lav: может не только не быть /usr (это сейчас и впрямь редкость), а и быть повреждено его содержимое -- "бомбе" легче попасть в большой раздел, чем в маленький, и повреждение _каталога_ /usr/lib64 в таком разе лишит сразу и аварийного редактора.  Но при этом действительно стоит соразмерять возможность аварии и плату за подстраховку в повседневной деятельности, как мне кажется.

(Ответ для Michael Shigorin на комментарий #6)
> (Ответ для Vitaly Lipatov на комментарий #4)
> > (Ответ для Dmitry V. Levin на комментарий #3)
> > > Правильная программа, которой нужно запустить редактор для редактирования
> > > временных файлов, выбирает редактор в следующем порядке:
> > > 1. $VISUAL
> > > 2. $EDITOR
> > > 3. vitmp(1)
> > Получается, бага висит не на той компоненте. Тогда нужно переместиться
> > в сторону пакетов или дистрибутивов, задающих эти переменные.
> Да, VISUAL можно было бы и выставлять (slave alternatives на profiles.d-файл
> или хотя бы просто "кто встал, того и тапки").

Обнаружил пакет nano-editor с единственным файлом
$ cat /etc/profile.d/nano-editor.sh
#!/bin/sh

[ -n "$EDITOR" ]  || export EDITOR="nano"

То есть вот уже такой шаг был:
* Ср июл 26 2017 Sergey V Turchin <zerg@altlinux.org> 0.1-alt1
- initial build

 
> (Ответ для Anton Farygin на комментарий #5)
...
> 2 lav: может не только не быть /usr (это сейчас и впрямь редкость), а и быть
> повреждено его содержимое -- "бомбе" легче попасть в большой раздел, чем в
> маленький, и повреждение _каталога_ /usr/lib64 в таком разе лишит сразу и
> аварийного редактора.  Но при этом действительно стоит соразмерять
> возможность аварии и плату за подстраховку в повседневной деятельности, как
> мне кажется.
С аварийным vi всё понятно, пусть будет всегда.

Речь о том, что VISUAL должна указывать на вменяемый редактор.
Мне кажется, было бы правильным управлять этим через control, а не установкой пакетов/альтернативами.
При этом варианты для выбора control бы нам показывал исходя из доступных команд.

Поскольку у меня уже есть control-umask, могу сделать control-editor.

(Ответ для Vitaly Lipatov на комментарий #7)
...
> Обнаружил пакет nano-editor с единственным файлом
> $ cat /etc/profile.d/nano-editor.sh
> #!/bin/sh
> 
> [ -n "$EDITOR" ]  || export EDITOR="nano"
> 
> То есть вот уже такой шаг был:
> * Ср июл 26 2017 Sergey V Turchin <zerg@altlinux.org> 0.1-alt1
> - initial build
> 
Случайно открыл для себя

 $ rpm -q --changelog mcedit-editor
* Чт янв 21 2021 Sergey V Turchin <zerg@altlinux.org> 0.2-alt1
- fix editor program

* Ср дек 16 2020 Sergey V Turchin <zerg@altlinux.org> 0.1-alt1
- initial build


 $ rpm -ql mcedit-editor
/etc/profile.d/mcedit-editor.csh
/etc/profile.d/mcedit-editor.sh

$ cat /etc/profile.d/mcedit-editor.sh

export EDITOR="mcedit"

(Ответ для Michael Shigorin на комментарий #6)
...
> 2 lav: может не только не быть /usr (это сейчас и впрямь редкость), а и быть
> повреждено его содержимое -- "бомбе" легче попасть в большой раздел, чем в
> маленький, и повреждение _каталога_ /usr/lib64 в таком разе лишит сразу и
> аварийного редактора.  Но при этом действительно стоит соразмерять
> возможность аварии и плату за подстраховку в повседневной деятельности, как
> мне кажется.
Да, вот прямо открытым текстом и написано, что есть аварийные случаи, для которых некий vi должен _присутствовать_ в системе и есть повседневная работа, в которой никакой аварийный редактор не сдался.
И всё, что мы обсуждаем, это ручки для управления и дистрибутивные умолчания.