geditを使用して「sudo -H gedit」でシステムファイルを編集するときに問題が発生することはありますか？

私はUbuntuに比較的慣れていませんが、このサイトの回答で、システムファイルの編集を提案されたときに、コマンドが常にsudo nanoまたはであることに気付きましたsudo vi。端末ベースのテキストエディターの使用が嫌いなため、通常は

sudo -H gedit

代わりに、これまでのところ、それは完全にうまくいきました。

を使用geditしてシステムファイルを編集するときに問題が発生することはありますか、それともテキストエディタの選択は完全にユーザーの好みに依存しますか？これらのファイルを編集するときに心に留めておくべきこと（エンコードなど）はありますか？

あなたがそれを正しく実行する限り、それはあなたの好みの問題です。

機能の違いは別として、実際に使用するテキストエディタはかなり好みです。これは、テキストエディターがGeditのようなグラフィカルプログラムである場合にも当てはまります。これは、そこには正当な理由がないだと言うことではないnanoとvimしばしば推奨されています。vim（または少なくともviコマンドのような）端末ベースのテキストエディタnanoは、GUIがなくても、ごくわずかで壊れたシステムでも使用できます。彼らは彼らの背後にいくつかの伝統を持っています（あなたがその種のものに偏っているなら）。これらは、他のタスクが実行されるのと同じターミナルで実行できます。ターミナルマルチプレクサーのユーザーのワークフローに自動的に統合されます。そして、それらは他よりも利用可能である可能性が高いです特定のグラフィカルテキストエディター、Gedit、Ubuntu（いくつかのフレーバー）でも。

それがすべてではありません。システムファイルを編集する場合、1つの方法として、エディターをルートとして実行します。これは唯一のアプローチではなく、それに反対する議論がありますが（以下を参照）、それは一般的なものです。あなたはそのアプローチを取る場合と、あなたのエディタとしてグラフィカルなプログラムを使用し、その後、必要な世話をするために、このような方法でそれを実行し$HOME、独自のではなく、rootのホームディレクトリをされ、これは手間と複雑さの別の層を追加します。しかし、あなたはすでにそうしています。あなたが実行しているsudo -H gedit、これは合理的な方法の一つです。それでも、その複雑さは、非グラフィカルエディターを提案する傾向があるもう1つの理由です。

多くの場合、グラフィカルプログラムは、非グラフィカルプログラムよりも複雑です。rootとしてより多くのものを実行することは一般に悪いことです。偶然によるものを含め、潜在的なバグのために、問題が発生する可能性がより多くあるからです。（vimただし、などの非グラフィカルテキストエディタも非常に洗練されており、多くの場合、さまざまなタスクを実行するために多数の外部プログラムを実行するように構成されています。）

ルートとしてエディターを実行する以外に、別の一般的なアプローチは、（非ルート）ユーザーとして実行している場合でもエディターが変更できるファイルを編集することです。これにより、ファイルへの変更は、希望するルート所有ファイルに伝播されます。変更する。詳細はかなり異なるため、これは抽象的に聞こえます。次の2つの主要な具体的なアプローチがあります。

sudoedit

これを行うかなり長い間行われている方法の 1つはsudoedit（と同じマニュアルページに記載されていますsudo）です。デフォルトでsudoeditは、デフォルトのテキストエディタを使用します。これは通常、グラフィカルプログラムではありません。しかし、あなたはを通して任意のエディタを使用するためにそれを伝えることができSUDO_EDITOR、VISUALまたはEDITOR 環境変数、それはその順序で調べ、。したがって、以下を実行できます。

VISUAL=gedit sudoedit filename

filenameファイルの相対パスまたは絶対パスに置き換えます。

これにより、編集するファイルの一時的なコピーが作成されます。コピーの所有者は、root（または元の所有者）ではなく、あなたです。テキストエディターが開き、一時コピーを編集できます。テキストエディタを閉じるときに、sudoedit実際に変更を加えたかどうかを確認します。あなたがした場合、それはコピーが一時コピーの修正バックを元に。

一方でsudoedit、グラフィカルエディタと連携し、それは端末ベースのエディタにも便利です。どちらの場合も、あなたのようなテキストエディタを実行すると、それはあなたがそれに実行コンフィギュレーション、およびその他のアクションがある他のもたらすそのファイルに加えた変更は、あなたによって実行されるよりも、少しのミスのいくつかの種類に対する保護を。

必要に応じて、これらの環境変数の1つを永続的に設定できます。SUDO_EDITOR他のものに使用されているので、おそらく最高です。ただし、に設定した場合、GUIが利用できない場合、geditなどのコマンドは、（常にではありませんが）仮想コンソールまたはSSHを介した場合と同様に機能しないことに注意してください。sudoedit filename

GVFS管理バックエンド

これを行うもう1つの新しい方法admin://は、従来のUnixスタイルのパスではなく、GVFS パスを介してファイルを開くことです。これについて教えてくれたpomskyに感謝します。ファイルを編集するためのGVFSパスが存在するのと同じように、他の点では編集に便利な場所にありません（たとえば、SSH経由で接続しているリモートマシン上にあるため）-GVFSはadmin://ファイルを編集するためのパスをサポートしていますあなたは所有していません。

これは概念的にはsudoedit、エディターを自分で実行し、エディターに表示されるファイルは編集が許可されているものです。ファイルを開こうとすると、認証が必要になります。これは通常のセキュリティ制限を回避する魔法の方法ではありません。

gedit admin:///path/to/filename

そこに/path/to/filenameは、で始まるファイルへの絶対パスが必要/です。したがって、の/後に3つの文字がありますadmin:。

エンコーディングやその他の設定は、理論的にはエディター構成の影響を受けます

ファイルのエンコーディングは、使用するエディタがグラフィカルであるかどうかに実際には影響されません。のような一部のエディターは、vimグラフィック（gvimコマンド）または非グラフィック（コマンド）のどちらでも操作できますvim。エンコーディングに関する質問への簡単な答えは、それについて心配する必要がないということです。これは、この回答の残りを読む必要がないという事実に十分に近いものです。

現在（および過去）のUbuntuリリースでは、これらのエディターをrootとして実行するようにコマンドsudo nanoをsudo vim実行$HOMEしていますが、まだホームディレクトリに設定されています。これは、エディターがデフォルトで、ルートの構成ではなくユーザーの構成を使用することを意味します。これらのエディターの構成（または、エディターがのような作業を行うために実行するプログラムgit）にエンコードまたは行の終わりについて何かがある場合は、それに従います。では、それは起こりません。sudo -H editor

一部の人々は裸の使用sudo（すなわち、なし-iか、-H彼らはそれをしたいので、編集者に）。しかし、実際には、これについて2度考えるべきです。のような方法でその目標をより明確に達成できるだけでなくsudoedit、sudo nanoおよびのようなコマンドには他にも欠点がありますsudo vim。

• エディターの構成により何かが実行される場合、それはrootとして実行されます。のような洗練されたエディタの場合vim、これにより、かなりの重要なコードがrootとして実行される可能性があります。上で述べたように、rootとして実行するコードを少なくすることは一般的に良いことであり、これはrootとしてグラフィカルエディターを実行することに対する反対論の1つです。

  vim構成に多数のプラグインがある場合（たとえば、入力時にソースコードで静的分析を実行する場合など）、rootはそうではない場合、rootとして実行されるものはと比べて少なくなります。（以下でもrootとしてで実行されますが、プラグインは引き続き機能します！）これは、エディターがグラフィカルであるかどうかとは異なります。sudo -H vim filenamesudo vim filenameVISUAL=vim sudoedit filename

• エディターの設定が壊れていて、ファイルを簡単に編集できない場合は、ルートにも適用されるため、修正はさらに面倒です。これは面倒なことであり、解決が難しい問題ではありません。

• のようなコマンドにsudo vimは、（よく知られていない！）コマンドと少し同じ問題がありsudo geditます。 あなたのようなエディタを実行する場合vim、ルートとしてではなくリセットせずに$HOME（ようsudo -Hとsudo -iするだろう）、それは自分自身のための設定ファイルを作成し、それらの設定ファイルがホームディレクトリに存在しますが、彼らは、ルートによって所有され、設定が多少破損する可能性が後でエディターを自分で実行したとき。

  まあ、これは確かにその問題のように聞こえます！グラフィカルアプリケーションよりも大した問題ではない理由は、通常はエディタが起動し、エラーメッセージが通常より理解しやすく、通常、影響を受ける特定のファイルがはるかに簡単にわかり、破損は通常、その1つのプログラム。（グラフィカルプログラムはより多くの場所で構成ファイルを使用します。）さらに、グラフィカルエディターとは異なり、テキストエディターをさりげなく使用し、その構成を意図的に変更しないユーザーは、この問題が発生する可能性はほとんどありません。

繰り返しますが、独自のユーザーアカウントのエディター構成を使用しながらsudoedit、デスクトップを使用するか、デスクトップからエディターを通常どおり起動してadmin://パスを介してファイルにアクセスすることにより、権限の問題を回避できます。

最後に、上記のsudowhen -Hまたはpassの動作は-i、Ubuntuの将来のリリースで変更される予定です（すでに数年前に、を使用するほとんどのUnixライクなオペレーティングシステムで既に変更されていますsudo）。この動作は、この記事の執筆時点での開発リリースであるUbuntu 19.10ですでに変更されています。

あなたの質問に答えるために：一般に、GUIエディターを使用しても、gedit大きなファイルの速度が非常に遅くなることは問題にはなりません。

ただし、GUIプログラムの場合は、pkexecまたはのgksu代わりに使用しますsudo。それが動作するpkexec前に構成する必要があるかもしれません。

pkexec gedit

または、古いUbuntuバージョン（16.04など）では、以下を使用できます。

gksu gedit

（たとえば、より良いGUIエディターを試してみるかもしれませんが、geany;-)）