Поки ви правильно його виконуєте, це питання ваших уподобань.
Окрім відмінностей у функціях , те, що текстовий редактор ви використовуєте, насправді значно ваші переваги. Це справедливо навіть тоді, коли ваш текстовий редактор є такою графічною програмою, як Gedit . Це не означає, що немає вагомих причин, nano
і vim
їх часто рекомендують. Текстові редактори на основі терміналів, як vim
(або принаймні vi
команди) nano
, доступні навіть тоді, коли немає графічного інтерфейсу і навіть у більшості дуже мінімальних та зламаних систем ; у них є певна традиція (якщо ви частково ставитеся до такого роду); їх можна запустити в тому ж терміналі, в якому виконуються інші завдання; вони автоматично інтегруються в робочі процеси термінальних мультиплексорів ; і вони швидше будуть доступні, ніж будь-якіособливий графічний текстовий редактор, навіть Gedit, навіть на Ubuntu (який має кілька ароматів ).
Це ще не все. Якщо ви збираєтеся редагувати системні файли, одним із підходів є запуск редактора як root. Це не єдиний підхід, і є деякі аргументи проти нього (див. Нижче), але він є загальним. Якщо ви скористаєтесь таким підходом і використовуєте графічну програму в якості свого редактора, тоді вам потрібно подбати про те, щоб запустити її таким чином, що $HOME
це домашній каталог root, а не ваш власний , і це додає ще один шар клопоту та складності. Але ти вже це робиш; Ви біжите sudo -H gedit
, що є одним із розумних способів . Однак ця складність є ще однією причиною, чому люди схильні пропонувати не графічні редактори.
Графічні програми часто складніші, ніж не графічні програми. Запуск більшої кількості матеріалів як root, як правило, поганий тим, що існує більше способів, як все може піти не так, в тому числі через можливі помилки, в тому числі випадково. (Не графічні редактори тексту, такі як vim
досить складні, вони часто налаштовані для запуску численних зовнішніх програм для виконання різних завдань.)
Окрім запуску редактора як root, ще одним загальним підходом є редагування файлу, який редактор здатний змінювати навіть під час роботи як вашого (некористувального) користувача, таким чином, щоб зміни у файлі поширювались на потрібний кореневий файл змінювати. Це звучить абстрактно, оскільки специфіка значно відрізняється. Випливають два основні конкретні підходи.
sudoedit
Один досить давній спосіб зробити це буде sudoedit
(описано в одній і тій же сторінці , як вручнуsudo
). За замовчуванням sudoedit
використовує текстовий редактор за замовчуванням , який, як правило, не є і не повинен бути графічною програмою. Але ви можете сказати йому , щоб використовувати будь-який редактор через SUDO_EDITOR
, VISUAL
або EDITOR
змінні оточення , які він проводить консультації в такому порядку. Таким чином ви можете запустити:
VISUAL=gedit sudoedit filename
Замініть filename
відносний або абсолютний шлях до файлу.
Це робить тимчасову копію файлу, який ви бажаєте редагувати. Копія належить вам, а не root (або тому, хто є первинним власником). Він відкриває текстовий редактор, і ви можете редагувати тимчасову копію. Коли ви закриєте текстовий редактор, sudoedit
перевірте, чи дійсно внесли зміни. Якщо ви це зробили, він копіює змінену тимчасову копію назад до оригіналу.
Хоча sudoedit
працює з графічними редакторами, це також корисно для редакторів на базі терміналів. В обох випадках, текстовий редактор працює , як ви, так що має конфігурацію, а також інші дії ви виконуєте в ній інший , ніж зміни , внесені в цей файл виконуються вами, який надає трохи захисту від деяких видів помилок.
Якщо ви хочете, ви можете постійно встановлювати одну із цих змінних середовища . SUDO_EDITOR
є, мабуть, найкращим, оскільки використовується для меншої кількості інших речей. Однак якщо ви встановите це gedit
, майте на увазі, що команди на зразок не працюватимуть, коли не доступний графічний інтерфейс, як це часто (хоча і не завжди ) відбувається у віртуальній консолі або через SSH .sudoedit filename
Повернення адміністратора GVFS
Ще один новий спосіб зробити це - відкрити файл через його admin://
шлях GVFS, а не традиційний шлях у стилі Unix. Дякую ідучи до Помського, що навчав мене про це. Так само, як є шляхи GVFS для редагування файлів, які, з іншого боку, не є зручним для редагування місцем, - наприклад, тому, що вони знаходяться на віддаленій машині, до якої ви підключені через SSH - GVFS підтримує admin://
шляхи редагування файлів ви не володієте.
Це концептуально схоже на sudoedit
те, що ви запускаєте свого редактора як власне, і файл, який редактор бачить, - це те, що йому дозволено редагувати. Спроба відкрити файл вимагає аутентифікації; це не магічний спосіб обійти звичайні обмеження безпеки.
gedit admin:///path/to/filename
Там /path/to/filename
повинен бути абсолютний шлях до файлу, починаючи з /
. Отже, після цього є три /
символи admin:
.
Кодування та інші речі теоретично впливають на конфігурацію редактора
На кодування файлу насправді не впливає чи графічний редактор, який ви використовуєте, чи ні. Деякі редактори, як-от vim
, навіть можуть працювати або графічно ( gvim
команда), або не графічно ( vim
команда). Проста відповідь на ваше запитання щодо кодування полягає в тому, що вам не доведеться турбуватися про це. Це досить близько до істини, що вам не потрібно читати решту цієї відповіді.
У поточних (і минулих) версіях Ubuntu, команди люблять sudo nano
і sudo vim
запускають ці редактори як корінь, але $HOME
все ще встановлені у вашій домашній директорії. Це означає, що редактори за замовчуванням використовуватимуть вашу конфігурацію, а не кореневу конфігурацію. Якщо у вашій конфігурації цих редакторів (або в програмі, яку вони виконують, наприклад, git
) є щось стосовно кодування або закінчень рядків , це буде дотримано. З , цього не станеться.sudo -H editor
Деякі люди використовують голі sudo
(тобто без -i
або -H
) для редакторів, тому що хочуть цього. Але дійсно, варто подумати над цим два рази. Ви можете не тільки досягти цієї мети більш чисто з методом , як sudoedit
, є й інші недоліки команд , як sudo nano
і sudo vim
:
Якщо конфігурація редактора викликає щось запуск, він запускається як root. Для таких складних редакторів, як vim
це, це може спричинити запуск трохи нетривіального коду як root. Як було сказано вище, менша кількість запуску коду як root, як правило, добре, і це один із аргументів проти роботи графічних редакторів як root.
Якщо у вашій vim
конфігурації є численні плагіни - наприклад, для того, щоб виконувати статичний аналіз вихідного коду під час його введення, а root - ні, менше елементів працює як root з, ніж . (Ще менше працює як root , але ваші плагіни все ще працюють!) Це окремо від того, чи ваш редактор графічний.sudo -H vim filename
sudo vim filename
VISUAL=vim sudoedit filename
Якщо конфігурація редактора порушена і не дозволяє вам легко редагувати файли, то виправлення може бути ще більшим клопотом, оскільки це стосується і кореня. Це просто клопітка, не складна вирішити проблему.
Команди , як sudo vim
є трохи тієї ж проблеми, що і (необачний!) Команди sudo gedit
. Якщо ви запускаєте такий редактор, як vim
root, але без скидання $HOME
(як sudo -H
і це sudo -i
було б), і він створює файли конфігурації для себе , ці файли конфігурації будуть знаходитися у вашій домашній директорії, але вони матимуть root, і ваша конфігурація може бути дещо зламана коли пізніше ви запускаєте редактор як себе.
Ну, це впевнено звучить як проблема! Причина, що це не так вже й багато, ніж із графічними програмами, полягає в тому, що редактор, як правило, все-таки запускається, повідомлення про помилки, як правило, простіше зрозуміти, зазвичай можна зрозуміти, які конкретні файли впливають набагато легше, а поломка зазвичай обмежується що одна програма. (Графічні програми використовують файли конфігурації в багатьох місцях.) Крім того, на відміну від графічних редакторів, у користувачів, які лише випадково використовують текстовий редактор і свідомо не змінюють його конфігурацію, навряд чи виникне ця проблема.
Знову ж таки, ви можете використовувати конфігурацію редактора власного облікового запису користувача, уникаючи проблем з дозволами, використовуючи sudoedit
або з робочого столу, запускаючи редактор зазвичай, але отримуючи доступ до файлу через admin://
шлях.
Нарешті, зауважте, що вищезазначена поведінка sudo
при передачі -H
або -i
передачі насправді планується змінити в майбутньому випуску Ubuntu (як це вже було років тому в більшості подібних Unix операційних систем, які використовують sudo
). Поведінка вже змінилася в Ubuntu 19.10 , що є версією розробки станом на цей текст.
-H
Частина важлива , що не слід використовуватиsudo
для запуску GUI додатків без нього.