проблемка мелкая,но нервы портит:
под sudo vim - не читает .vimrc(нет подсветки,нумерации, в общем не читает настройки) и собственно вопрос:как научить читать vim .vimrc под sudo?
проблемка мелкая,но нервы портит:
под sudo vim - не читает .vimrc(нет подсветки,нумерации, в общем не читает настройки) и собственно вопрос:как научить читать vim .vimrc под sudo?
сделайте копию .vimrc в каталоге /root/
"Lupo Alberto" написал:
Или попробовать с помощью опции -u указать vim нужный файл конфигурации.
"Lupo Alberto" написал:
sudo -E vim
довольно опасное решение. Злоумышленник может подсунуть свой скрипт вместо конфига. Намного более безопасно использовать отдельный конфиг (как обычно, желательно установить его права 0600, и владелец root:root)
Максимально защищённое решение - использовать vim в безопасном режиме
Avoiding trojan horses: *trojan-horse*
While reading the "vimrc" or the "exrc" file in the current directory, some
commands can be disabled for security reasons by setting the 'secure' option.
This is always done when executing the command from a tags file. Otherwise it
would be possible that you accidentally use a vimrc or tags file that somebody
else created and contains nasty commands. The disabled commands are the ones
that start a shell, the ones that write to a file, and ":autocmd". The ":map"
commands are echoed, so you can see which keys are being mapped.
If you want Vim to execute all commands in a local vimrc file, you
can reset the 'secure' option in the EXINIT or VIMINIT environment variable or
in the global "exrc" or "vimrc" file. This is not possible in "vimrc" or
"exrc" in the current directory, for obvious reasons.
On Unix systems, this only happens if you are not the owner of the
vimrc file. Warning: If you unpack an archive that contains a vimrc or exrc
file, it will be owned by you. You won't have the security protection. Check
the vimrc file before you start Vim in that directory, or reset the 'exrc'
option. Some Unix systems allow a user to do "chown" on a file. This makes
it possible for another user to create a nasty vimrc and make you the owner.
Be careful!
When using tag search commands, executing the search command (the last
part of the line in the tags file) is always done in secure mode. This works
just like executing a command from a vimrc/exrc in the current directory.
не знаю как у вас, а у нас в Slackware просто появится файл /etc/vim/vimrc.new, который затем можно исследывать diff'ом на предмет новых опций. Но такое редко бывает, формат конфига меняется очень редко.
У «нас» появится новый конфигурационного файла, к имени которого допишется нижнее подчёркивание и временная метка, старый файл, останется на месте, будет предложено запустить etc-update, чтобы принять решение о «замене/интерактивном слиянии/незамене» файлов.
Формат файла не поменяется, поменяются опции настройки, указанные в нём, это очевидно, иначе не было бы смысла в его переписывании. Способ копирования файл имеет право на жизнь в системе с одним пользователем и то с учётом вышепреведённого.
Я, как и вы, просто копирую пользовательский файл в домашний каталог root, разумеется, изменив к нему права доступа.
У «нас» появится новый конфигурационного файла, к имени которого допишется нижнее подчёркивание и временная метка, старый файл, останется на месте, будет предложено запустить etc-update, чтобы принять решение о «замене/интерактивном слиянии/незамене» файлов.
у нас тоже так иногда бывает. Если есть что менять.
"Lupo Alberto" написал:
Способ копирования файл имеет право на жизнь в системе с одним пользователем и то с учётом вышепреведённого.
не, ну почему? Как раз, если юзеров много, то иметь общий конфиг довольно удобно. При этом каждый юзер не теряет возможность заменить/дополнить общие настройки своими личными.
"Lupo Alberto" написал:
Я, как и вы, просто копирую пользовательский файл в домашний каталог root, разумеется, изменив к нему права доступа.
Вроде, как-то обновлялся, так и работает, я ничего не менял...
"drBatty" написал:
а у нас в Slackware просто появится файл /etc/vim/vimrc.new
Понятно, что старый файл остаётся на месте, но какие-нибудь новые «фичи» могут пройти мимо.
P.S. В некоторых дистрибутивах файлы могут переписываться.
P.S.S. Не считаю такой способ каким-то особенно «порочным», однако, на мой взгляд, он противоречит парадигме применения опций конфигурации — так в Gentoo, например, наибольшим приоритетом пользуются опции, передаваемые в командной строке, затем — пользовательские и в последнюю очередь, по-дефолту — общесистемные.
Понятно, что старый файл остаётся на месте, но какие-нибудь новые «фичи» могут пройти мимо.
дык у нас тоже есть diff старого с новым файлов. Т.ч. всё норм.
"Lupo Alberto" написал:
В некоторых дистрибутивах файлы могут переписываться.
ну... руки надо некоторым маинтейнерам отрывать :)
"Lupo Alberto" написал:
Не считаю такой способ каким-то особенно «порочным», однако, на мой взгляд, он противоречит парадигме применения опций конфигурации — так в Gentoo, например, наибольшим приоритетом пользуются опции, передаваемые в командной строке, затем — пользовательские и в последнюю очередь, по-дефолту — общесистемные.
всё верно - именно так и ведёт себя vim. Никакого нарушения я не наблюдаю. Я не очень понял, ЧТО нужно ТСу, если сменить общесистемные настройки, то способ через /etc/vim/vimrc самый правильный, а вот если root'овые, то правильнее /root/.vimrc. ИМХО лучше таки эти файлы разделять, и использовать рутовый vim _только_ для редактирования системных конфигов. А для всего прочего пойдёт юзерский vim, в который можно напихать разных нужных плюшек.
И будет как у username. Возможно понадобится также скопировать ~/.vim/ со всем содержимым. У меня например там изменённая цветовая схема и ещё какие-то фишки нужные.
На самом деле настройки храняться (в порядке возрастания приоритета)
1. /usr/share/vim/ (это не нужно менять. Это конфиг по умолчанию. Его можно использовать как заготовка для своих целей)
2. /etc/vim/ конфиг для всех юзеров.
3. ~/.vimrc и ~/.vim - личный конфиг конкретного юзера.
Если вы пользуетесь sudo, то вы меняете юзера, и если у него нет личного конфига, срабатывает п2 или п1.
Конфиг высокого приоритета не отменяет конфиг низкого, но перекрывает его.
