sudo emacs doesn't read my elpa packages
Clash Royale CLAN TAG#URR8PPP
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.
centos sudo emacs
asked Dec 14 at 3:04
Chap
160113
add a comment |
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.
centos sudo emacs
asked Dec 14 at 3:04
Chap
160113
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
– Panther
Dec 14 at 5:46
1
Whysudo emacsat all?sudoeditis far better, since it doesn't require emacs itself to run as root
– Fox
Dec 14 at 5:49
1
The combination of the first and fourth bullet points is very, very strange.
– Michael Homer
Dec 14 at 6:23
@MichaelHomer you are correct; I was mistaken. Actual behavior is consistent with bullet 1. I've edited the original post.
– Chap
Dec 14 at 15:24
@Foxsudoeditworked just fine! Your comment appears to have solved my problem ($EDITOR is emacs). Feel free to post as answer.
– Chap
Dec 14 at 15:31
add a comment |
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.
centos sudo emacs
asked Dec 14 at 3:04
Chap
160113
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.
centos sudo emacs
centos sudo emacs
asked Dec 14 at 3:04
Chap
160113
asked Dec 14 at 3:04
Chap
160113
edited Dec 14 at 15:22
asked Dec 14 at 3:04
Chap
160113
asked Dec 14 at 3:04
Chap
160113
asked Dec 14 at 3:04
Chap
160113
160113
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
– Panther
Dec 14 at 5:46
1
Whysudo emacsat all?sudoeditis far better, since it doesn't require emacs itself to run as root
– Fox
Dec 14 at 5:49
1
The combination of the first and fourth bullet points is very, very strange.
– Michael Homer
Dec 14 at 6:23
@MichaelHomer you are correct; I was mistaken. Actual behavior is consistent with bullet 1. I've edited the original post.
– Chap
Dec 14 at 15:24
@Foxsudoeditworked just fine! Your comment appears to have solved my problem ($EDITOR is emacs). Feel free to post as answer.
– Chap
Dec 14 at 15:31
add a comment |
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
– Panther
Dec 14 at 5:46
1
Whysudo emacsat all?sudoeditis far better, since it doesn't require emacs itself to run as root
– Fox
Dec 14 at 5:49
1
The combination of the first and fourth bullet points is very, very strange.
– Michael Homer
Dec 14 at 6:23
@MichaelHomer you are correct; I was mistaken. Actual behavior is consistent with bullet 1. I've edited the original post.
– Chap
Dec 14 at 15:24
@Foxsudoeditworked just fine! Your comment appears to have solved my problem ($EDITOR is emacs). Feel free to post as answer.
– Chap
Dec 14 at 15:31
3
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
– Panther
Dec 14 at 5:46
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
– Panther
Dec 14 at 5:46
1
1
Why
sudo emacs at all? sudoedit is far better, since it doesn't require emacs itself to run as root– Fox
Dec 14 at 5:49
Why
sudo emacs at all? sudoedit is far better, since it doesn't require emacs itself to run as root– Fox
Dec 14 at 5:49
1
1
The combination of the first and fourth bullet points is very, very strange.
– Michael Homer
Dec 14 at 6:23
The combination of the first and fourth bullet points is very, very strange.
– Michael Homer
Dec 14 at 6:23
@MichaelHomer you are correct; I was mistaken. Actual behavior is consistent with bullet 1. I've edited the original post.
– Chap
Dec 14 at 15:24
@MichaelHomer you are correct; I was mistaken. Actual behavior is consistent with bullet 1. I've edited the original post.
– Chap
Dec 14 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.– Chap
Dec 14 at 15:31
@Fox
sudoedit worked just fine! Your comment appears to have solved my problem ($EDITOR is emacs). Feel free to post as answer.– Chap
Dec 14 at 15:31
add a comment |
1 Answer
1
active
oldest
votes
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.
answered Dec 15 at 8:18
Fox
5,16611232
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f487907%2fsudo-emacs-doesnt-read-my-elpa-packages%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Dec 15 at 8:18
Fox
5,16611232
add a comment |
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.
answered Dec 15 at 8:18
Fox
5,16611232
add a comment |
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.
answered Dec 15 at 8:18
Fox
5,16611232
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.
answered Dec 15 at 8:18
Fox
5,16611232
answered Dec 15 at 8:18
Fox
5,16611232
answered Dec 15 at 8:18
Fox
5,16611232
answered Dec 15 at 8:18
Fox
5,16611232
5,16611232
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f487907%2fsudo-emacs-doesnt-read-my-elpa-packages%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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
– Panther
Dec 14 at 5:46
1
Why
sudo emacsat all?sudoeditis far better, since it doesn't require emacs itself to run as root– Fox
Dec 14 at 5:49
1
The combination of the first and fourth bullet points is very, very strange.
– Michael Homer
Dec 14 at 6:23
@MichaelHomer you are correct; I was mistaken. Actual behavior is consistent with bullet 1. I've edited the original post.
– Chap
Dec 14 at 15:24
@Fox
sudoeditworked just fine! Your comment appears to have solved my problem ($EDITOR is emacs). Feel free to post as answer.– Chap
Dec 14 at 15:31