Могут ли возникнуть какие-либо проблемы при использовании gedit для редактирования системных файлов с помощью & # 39; sudo -H gedit &????????????????????????????????????????????????

Пока Вы выполняете его правильно, это - вопрос Вашего предпочтения.

Кроме различий в функциях, какой текстовый редактор Вы используете, действительно в значительной степени Ваше предпочтение. Это верно, даже когда Ваш текстовый редактор является графической программой как Gedit. Это не должно говорить, что нет никакого серьезного основания nano и vim часто рекомендуются. На терминальном основанные текстовые редакторы как vim (или по крайней мере a vi команда) и nano доступны, даже когда нет никакого GUI и даже в большинстве очень минимальных и поврежденных систем; у них есть некоторая традиция позади них (если Вы неравнодушны к такой вещи); они могут быть выполнены в том же терминале, в котором выполняются другие задачи; они автоматически интегрируются в рабочие процессы пользователей оконечного мультиплексора; и они, более вероятно, будут доступны, чем какой-либо конкретный графический текстовый редактор, даже Gedit, даже на Ubuntu (который имеет несколько разновидностей).

Это не все. Если Вы собираетесь отредактировать системные файлы, один подход должен выполнить Вашего редактора как корень. Это не единственный подход, и существуют некоторые аргументы против него (см. ниже), но это - общее. Если Вы проявляете тот подход и используете графическую программу в качестве Вашего редактора, то необходимо заботиться для выполнения его таким способом который $HOME корневой каталог корня, а не Ваше собственное, и это добавляет другой слой стычки и сложности. Но Вы уже делаете это; Вы работаете sudo -H gedit, который является одним из разумных путей. Однако, та сложность является другой причиной, люди склонны предлагать неграфических редакторов.

Графические программы часто более сложны, чем неграфические программы. При наличии большего количества материала, выполненного, поскольку, корень обычно плох, в этом существует больше способов, включая которые вещи могли пойти не так, как надо, включая должный к возможным ошибкам, случайно. (Неграфические текстовые редакторы такой как vim довольно сложны слишком, тем не менее, и часто настраиваются для запущения многочисленных внешних программ для выполнения различных задач.)

Помимо выполнения редактора как корень, другой общий подход должен отредактировать файл, который редактор может изменить, работая как Ваш (некорневой) пользователь, такой, что изменения в файле распространены в корневой файл, который Вы хотите изменить. Это звучит абстрактным, потому что специфические особенности значительно варьируются. Два основных конкретных подхода следуют.

sudoedit

Один довольно давний способ сделать это sudoedit (зарегистрированный в ту же страницу руководства как sudo). По умолчанию, sudoedit использует текстовый редактор по умолчанию, который обычно является не - и не должен быть - графическая программа. Но можно сказать этому использовать любого редактора через SUDO_EDITOR, VISUAL, или EDITOR переменные среды, с которыми это консультируется в том порядке. Таким образом можно работать:

VISUAL=gedit sudoedit filename

Замена filename с относительным или полным путем в Ваш файл.

Это делает временную копию файла, который Вы хотите отредактировать. Копия принадлежит Вам, не корню (или кто бы ни первоначальный владелец). Это открывает текстовый редактор, и можно отредактировать временную копию. Когда Вы закрываете текстовый редактор, sudoedit проверки, если Вы на самом деле внесли изменения. Если Вы сделали, это копирует измененную временную копию назад в оригинал.

В то время как sudoedit работы с графическими редакторами, это также полезно для на терминальном основанных редакторов. В обоих случаях текстовый редактор работает как Вы, таким образом, он имеет Вашу конфигурацию, и другие действия, которые Вы выполняете в нем кроме модификаций, сделанных в тот файл, выполняются Вами, который предоставляет немного защиты от некоторых видов ошибок.

Можно установить одну из тех переменных среды постоянно, если Вам нравится. SUDO_EDITOR является, возможно, лучшим, так как это используется для меньшего количества других вещей. Однако, если Вы устанавливаете его на gedit, имейте в виду что команды как sudoedit filename не будет работать, когда никакой GUI не доступен, как часто (хотя не всегда) случай в виртуальной консоли или через SSH.

Администраторский бэкенд GVFS

Другой более новый способ сделать это, должен открыть файл через его GVFS admin:// путь, а не его традиционный путь стиля Unix. Спасибо переходит к pomsky для обучения меня об этом. Так же, как существуют пути 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:

• Если Ваша конфигурация редактора заставляет что-то быть выполненным, который выполняется как корень. Для сложных редакторов как vim, это может заставить довольно мало нетривиального кода работать как корень. Как упомянуто выше, имея меньше кода, выполненного, поскольку, корень обычно хорош, и это - один из аргументов против выполнения графических редакторов как корень.

  Если Ваш vim конфигурация имеет многочисленные плагины - например, для выполнения статического анализа исходного кода, поскольку Вы вводите его - и корень не делает, меньше выполнений материала как корень с sudo -H vim filename чем sudo vim filename. (Еще меньше выполнений как корень с VISUAL=vim sudoedit filename, но Ваши плагины все еще работают!) Это является отдельным от того, является ли Ваш редактор графическим.

• Если Ваша конфигурация редактора повреждается и мешает Вам редактировать файлы легко, то фиксация, которая может быть еще большим количеством стычки, так как она применяется к корню, также. Это - просто стычка, не трудная проблема для решения.

• Команды как sudo vim имейте немного та же проблема как (опрометчивый!) команда sudo gedit. Если Вы выполняете редактора как vim как базируются, но без сброса $HOME (как sudo -H и sudo -i сделал бы), и это создает конфигурационные файлы для себя, те конфигурационные файлы будут находиться в Вашем корневом каталоге, но они будут принадлежать корню, и Ваша конфигурация может быть несколько повреждена при позже выполнении редактора как сами.

  Ну, это верные звуки много как эта проблема! Причина это - меньше грандиозного предприятия, чем с графическими приложениями, состоит в том, что редактор обычно все еще запускает, сообщения об ошибках обычно легче понять, можно обычно выяснять, какие определенные файлы затронуты намного более легко, и поломка обычно ограничивается той одной программой. (Графические программы используют конфигурационные файлы в большем количестве мест.), Кроме того, в отличие от этого, с графическими редакторами, пользователи, которые только небрежно используют текстовый редактор и сознательно не изменяют его конфигурацию, довольно вряд ли испытают эту проблему.

Снова, можно использовать конфигурацию редактора собственной учетной записи пользователя при предотвращении проблем полномочий при помощи sudoedit или, от рабочего стола, запуская редактора обычно, но получая доступ к файлу через admin:// путь.

Наконец, обратите внимание что вышеупомянутое поведение sudo когда -H или -i передается на самом деле планируется для изменения в будущем релизе Ubuntu (поскольку она уже имеет, несколько лет назад, в большинстве подобных Unix операционных систем то использование sudo). Поведение уже изменилось в Ubuntu 19.10, которая является выпуском разработки с этой записи.

Отвечать на Ваш вопрос: В целом использование редактора GUI не будет проблемой независимо от gedit будучи очень медленным для больших файлов.

Но для программ GUI Вы использовали бы pkexec или gksu вместо sudo. Вы, возможно, должны настроить pkexec прежде чем это будет работать.

pkexec gedit

или для более старых версий Ubuntu (например, 16.04) можно использовать:

gksu gedit

(Хотя Вы могли бы судить лучших редакторов GUI, например. geany ;-) )