Ubuntu – Can there ever be any problem when using gedit to edit system files with ‘sudo -H gedit’

So long as you run it correctly, it's a matter of your preference.

Aside from differences in features, what text editor you use is indeed pretty much your preference. This is true even when your text editor is a graphical program like Gedit. This isn't to say there's no good reason nano and vim are often recommended. Terminal-based text editors like vim (or at least a vi command) and nano are available even when there's no GUI and even on most very minimal and broken systems; they have some tradition behind them (if you're partial to that sort of thing); they can be run in the same terminal in which other tasks are performed; they automatically integrate into terminal multiplexer users' workflows; and they are more likely to be available than any particular graphical text editor, even Gedit, even on Ubuntu (which has several flavors).

That's not all. If you're going to edit system files, one approach is to run your editor as root. This is not the only approach, and there are some arguments against it (see below), but it is a common one. If you take that approach and use a graphical program as your editor, then you need to take care to run it in such a way that $HOME is root's home directory rather than your own, and this adds another layer of hassle and complexity. But you're already doing that; you're running sudo -H gedit, which is one of the reasonable ways. Still, that complexity is another reason people tend to suggest non-graphical editors.

Graphical programs are often more complicated than non-graphical programs. Having more stuff run as root is generally bad, in that there are more ways things could go wrong, including due to possible bugs, including by accident. (Non-graphical text editors such as vim are quite sophisticated too, though, and are often configured to run numerous external programs to perform various tasks.)

Besides running the editor as root, another general approach is to edit a file that the editor is able to modify even when running as your (non-root) user, such that changes to the file are propagated to the root-owned file you wish to change. That sounds abstract because the specifics vary considerably. Two major concrete approaches follow.

sudoedit

One fairly long-standing way to do this is sudoedit (documented in the same manual page as sudo). By default, sudoedit uses the default text editor, which is usually not--and should not be--a graphical program. But you can tell it to use any editor through the SUDO_EDITOR, VISUAL, or EDITOR environment variables, which it consults in that order. Thus you can run:

VISUAL=gedit sudoedit filename

Replace filename with a relative or absolute path to your file.

This makes a temporary copy of the file you wish to edit. The copy is owned by you, not by root (or whoever the original owner is). It opens the text editor, and you can edit the temporary copy. When you close the text editor, sudoedit checks if you actually made changes. If you did, it copies the modified temporary copy back to the original.

While sudoedit works with graphical editors, it's also useful for terminal-based editors. In both cases, the text editor runs as you, so it has your configuration, and other actions you perform in it other than the modifications made to that file are performed by you, which affords a bit of protection against some kinds of mistakes.

You can set one of those environment variables persistently if you like. SUDO_EDITOR is perhaps the best since it's used for fewer other things. However, if you set it to gedit, keep in mind that commands like sudoedit filename won't work when no GUI is available, as is often (albeit not always) the case in a virtual console or via SSH.

The GVFS admin backend

Another newer way to do this, is to open the file through its GVFS admin:// path rather than its traditional Unix-style path. Thanks go to pomsky for teaching me about this. Just as there are GVFS paths for editing files that are, in other respects, not in a convenient place to be edited--for example because they are on a remote machine you're connected to through SSH--GVFS supports admin:// paths for editing files you don't own.

This is conceptually similar to sudoedit in that you run your editor as yourself and the file the editor sees is something it is allowed to edit. Attempting to open the file requires you to authenticate; this is not a magical way to circumvent usual security restrictions.

gedit admin:///path/to/filename

There, /path/to/filename must be an absolute path to the file, starting with /. So there are three / characters after admin:.

Encodings and other stuff theoretically affected by editor configuration

The encoding of a file is not really affected by whether or not the editor you use is graphical. Some editors, like vim, even can operate either graphically (the gvim command) or non-graphically (the vim command). The simple answer to your question about encodings is that you don't have to worry about that. That's close enough to the truth that you really don't have to read the rest of this answer.

In current (and past) Ubuntu releases, commands like sudo nano and sudo vim run those editors as root but have $HOME still set to your home directory. This means the editors will, by default, use your configuration rather than root's configuration. If there's something in your configuration of those editors (or in a program they run to do some of their work, like git) about encodings or line endings, it will be followed. With sudo -H editor, that won't happen.

Some people use bare sudo (i.e., without -i or -H) to editors because they want that. But really, you should think twice about this. Not only can you achieve that goal more cleanly with a method like sudoedit, there are other disadvantages of commands like sudo nano and sudo vim:

• If your editor configuration causes something to be run, that gets run as root. For sophisticated editors like vim, this can cause quite a bit of nontrivial code to run as root. As mentioned above, having less code run as root is generally good and this is one of the arguments against running graphical editors as root.

  If your vim configuration has numerous plugins--for example, to perform static analysis on source code as you type it--and root's doesn't, less stuff runs as root with sudo -H vim filename than sudo vim filename. (Even less runs as root with VISUAL=vim sudoedit filename, but your plugins still work!) This is separate from whether or not your editor is graphical.

• If your editor configuration is broken and keeps you from editing files easily, then fixing that may be even more of a hassle, since it applies to root, too. This is merely a hassle, not a difficult problem to solve.

• Commands like sudo vim have a bit of the same problem as the (ill-advised!) command sudo gedit. If you run an editor like vim as root but without resetting $HOME (as sudo -H and sudo -i would do), and it creates configuration files for itself, those configuration files will reside in your home directory but they will be owned by root, and your configuration may be somewhat broken when you later run the editor as yourself.

  Well, this sure sounds a lot like that problem! The reason it's less of a big deal than with graphical applications is that the editor usually still starts, the error messages are usually easier to understand, you can usually figure out what specific files are affected much more easily, and the breakage is typically confined to that one program. (Graphical programs use configuration files in more places.) Furthermore, unlike with graphical editors, users who only casually use a text editor and don't deliberately change its configuration are fairly unlikely to experience this problem.

Again, you can use your own user account's editor configuration while avoiding permissions problems by using sudoedit or, from the desktop, starting the editor normally but accessing the file through an admin:// path.

Finally, note that the above-mentioned behavior of sudo when -H or -i is passed is actually planned to change in a future release of Ubuntu (as it already has, years ago, in most Unix-like operating systems that use sudo). The behavior has already changed in Ubuntu 19.10, which is the development release as of this writing.