1

Here is my problem on a server running CentOS 7 with emacs 24.3.1.:

  • When I run sudo emacs <protected_file> on a file that I don't have write permissions, emacs doesn't read my .emacs file, nor does it recognize the commands defined in .emacs.d/elpa/.
  • When I run sudo emacs -u myuserid <protected_file> on that file, emacs reads my .emacs file but still doesn't know about my elpa packages.
  • When I run emacs <protected_file>, it reads .emacs and knows about .emacs.d/elpa packages. (But the file is opened in read-only mode, of course.)
  • When I run sudo emacs <myfile> on a file I have write permission on, emacs doesn't read my .emacs file, nor does it recognize the commands defined in .emacs.d/elpa/.
  • emacs <myfile> works as expected.

However, on the server that I copied my home directory from, which runs CentOS 6 with emacs 23.1.1, everything works fine. sudo emacs <protected_file> reads .emacs and it recognizes the commands within .emacs.d/elpa/.

I've verified that the file and directory permissions in my home directory are identical on both servers.

Since both the OS level and the emacs level are different, it seems like it could be either sudo or emacs where the problem lies (or in the way the systems people configured the new server).

Any ideas about this odd behavior?

UPDATE: Original post stated in bullet 4 that sudo emacs <myfile> worked as expected. This wasn't true, and I've amended that above.

Improve this question
5
  • 3
    Your problem is that sudo , depending on how it is configured, does NOT use your user's environmental variables, it uses root's. So ~ is /root so you need to put the .emacs stuff you want in /roor/.emacs (I go best) and configure root's path, or use the full path to files rather than ~ or . Or , imo less preferable, configure sudo to use your user environmental variables . See man sudo for details Commented Dec 14, 2018 at 5:46
  • 1
    Why sudo emacs at all? sudoedit is far better, since it doesn't require emacs itself to run as root Commented Dec 14, 2018 at 5:49
  • 1
    The combination of the first and fourth bullet points is very, very strange. Commented Dec 14, 2018 at 6:23
  • @MichaelHomer you are correct; I was mistaken. Actual behavior is consistent with bullet 1. I've edited the original post. Commented Dec 14, 2018 at 15:24
  • @Fox sudoedit worked just fine! Your comment appears to have solved my problem ($EDITOR is emacs). Feel free to post as answer. Commented Dec 14, 2018 at 15:31

1 Answer 1

Reset to default
1

The issue here is that when running your editor via sudo, it will use root's environment instead of your own. You could just configure the editor the same way for root as for your normal user, but obviously this doesn't extend well to systems where more than one person has sudo access.

The simplest solution, then, is to not run the editor under sudo. Just copy the original file, modify the copy, and copy it back over the original. Here, only the copy operations may need escalated privileges. On many systems, you can use this approach with

$ sudoedit /path/to/file

This will run $SUDO_EDITOR, $VISUAL, or $EDITOR (checked in that order) with standard privileges on a temporary copy of the target file and commit the changes to the original after the editor exits.

If your editor is set to emacsclient instead of just emacs, and you have an open emacs in server mode, you only have to close the buffer (not emacs as a whole) to commit the changes.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.