I notice that in some people's answers say "to edit the file, do sudo gedit $file" some people say "sudo nano $file" and of course "sudo vim $file"

By default doing "sudoedit $file" will open the file in the user's preferred editor. I think this is handy because documentation can be consistent regardless of what editor the user prefers. Thoughts?

  • what about sudo sensible-editor file?
    – lfaraone
    Commented Aug 21, 2010 at 13:49
  • @lfaraone The first time sensible-editor is run, it lets the user select what editor to use. If the first run is with sudo then it will presumably store this configuration information in the non-root user's configuration (as the default behavior of sudo is to use $HOME from the running user's environment), likely rendering the particular configuration file inaccessible (or at least unchangeable) by the non-root user. Therefore, I doubt it would be a good idea to recommend this approach. Commented Nov 28, 2011 at 0:52

3 Answers 3


I slightly disagree. This assumes the user is competent with a text-mode editor which they might not be. When supporting a mixed range of user competency (which we are) I find it's often better to cater to the lowest common denominator. In this case that means keeping them in a GUI environment as much as possible.

gksu gedit for Gnome/Ubuntu and kdesudo kate for KDE/Kubuntu (etc) seem like safer bets. Experienced users could easily sub in their editor of choice.

Of course for things that have to be done via the command line, sudoedit is great. IMO this includes tasks where there are multiple commands to be fired off and it's not practical to keep opening Run dialogues.

  • Fair enough. Do you think for new users explaining how to set gedit to be $EDITOR would be a better way to go though? Commented Aug 21, 2010 at 16:15
  • 1
    @JorgeCastro In November '11, I commented wrongly that (a) setting the VISUAL environment variable as gedit causes sudoedit run gedit as root, writing root-owned config files to the user's home directory (like sudo gedit does) and (b) using EDITOR instead of VISUAL would avoid this. I was totally wrong. sudoedit runs an editor as the caller, edits a temp file, and writes changes as root after the editor is closed. And sudoedit uses VISUAL and EDITOR (and SUDO_EDITOR), so if my first claim were true, the "fix" would fail. My apologies to everyone! Commented May 7, 2015 at 18:12

I think this is a great idea - for a few reasons:

  1. I had no idea sudoedit even exisited! So plus one on learning something
  2. This provides the asker of the question - and eventually other answer seekers - a uniform way of performing actions. I myself know enough that I personally love nano for text editing. But just like Vi, nano is a beast of its own to learn to use. For someone who is new and knows only of GUI editors, that's a big step to make.

sudoedit is an abstract reference, that is it will point by default to the editor selected by the distribution, or if the default is overridden to whatever editor selected see http://www.cs-repository.info/. This override likely would be caught by a system admin, but not by an inexperienced user (who could have actually made the changes). The danger here is the non-default editor could have shell escapes. An additional caution is that an example presented pedagogically would be different if the default editor had be changed to vi or emacs both of which have been defaults for sudoedit in the past, or other editor. vi is currently the default choice of http://www.sudo.ws/sudo/sudo.html

nano is a specific GNU editor with no shell escapes (and is the default sudoedit editor in later distributions of Ubuntu). When executed with the "-B" ( or "--backup") option it offers safety and relative ease for superuser editing using the terminal.

gksu gedit is excellent for this purpose and favored by the command-line phobic or command-line adverse. I after 45 years in this business used it until I discovered nano.

My idea⋯offer gksu gedit $file or nano -B $file with the other as an alternative and leave sudoedit alone.

Personally, I would never recommend sudoedit to a non-sysadmin.

That's my 12₵ worth (2₵ in '65 dollars)

O.K., another 12₵ worth…

First of all, when I was first introduced to sudo I didn't like it. After all, when I first started using computers, the terminal was a real teletype machine.

But I've learned to go with the flow, and there were some very good reasons to use sudo, a good synopsis is here. Basically for the inexperienced user it helps prevent unintended consequences when superusing (or super like using).

But the protection of sudo can be breached by shell escapes (i.e. http://docstore.mik.ua/orelly/unix/upt/ch30_26.htm), notably vi, which allows a user run commands in a subshell, as an superuser.

A senario is an inexperienced user finds out that he can change sudo while mucking about on the Internet(i.e. diddling with /etc/sudoers) to, for example, use sudo without requiring a password . He does this and then discovers all the other cool things he can do. The unintended consequence here is that the inexperienced user may not grasp all the implications of sudo visudo. Abstraction e.g. sudoedit and sudo visudo contribute to unintended consequences.

  • Of course trying to protect users from these things is like herding cats.

nano is a great choice for inexperienced users (and for me who likes to eschew the command-line when practical) in that it is most like GUI editors. I'm confident that's why Ubuntu selected it as the default editor of sudoedit.

But my thinking is to avoid abstraction unless it has obvious benefits, hence sudo nano -B vice sudoedit and occasionally gksu gedit $file (or gksu jEdit $file if I'm amped up).

  • The nub of the discussion is how far to go herding cats.
  • 1
    I don't get why it wouldn't be a recommendation. For normal people they would get nano, and everyone else would get whatever editor they defined. Commented Nov 27, 2011 at 1:59
  • Jorge - I've expanding my thinking in an edit Commented Nov 27, 2011 at 16:44
  • As far as I can tell from the sudoedit manual, the editor doesn't run with superuser privileges, so that shell escapes aren't the danger you suggest.
    – dcorking
    Commented Dec 30, 2015 at 11:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .