Предлагаю сделать так, чтобы во всех неаварийных случаях программы, вызывающие дефолтный редактор, не вызывали vi, который у нас в пакете vim-minimal, а вызвали vim, или другой редактор, назначенный на системном или пользовательском уровне в качестве дефолтного. Кстати, необходимость отдельного урезанного vi держится на рассказах о мифических авариях, при которых не смонтирован /usr, но посмотрите уже на Fedora, где /bin — это ссылка на /usr/bin. По поводу неудобства vi в качестве дефолта уже насоздавали кучу багов, наболтали кучу текста, а толку — ноль. Давайте уже либо призна́ем, что /bin/vi — это де-факто ссылка на дефолтный редактор, либо продолжим это отрицать и обозначим настройку (задание EDITOR) на системном и пользовательском уровне в виде дистрибутивного решения. По мне так, если кто-то оказывается в аварийной ситуации, пусть использует ed. Когда-то я в строчном редакторе писал программы на тысячи строк — ничего, вполне себе. Даже не думал, что возможно по-другому.
(В ответ на комментарий №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 должен _присутствовать_ в системе и есть повседневная работа, в которой никакой аварийный редактор не сдался. И всё, что мы обсуждаем, это ручки для управления и дистрибутивные умолчания.
