I had this exact same problem but it had nothing to do with RVM on ( which I also have ) on my Ubuntu-16.10 machine. It was related to by custom prompt (PS1)
The issue was the prompt PS1.
This fix : https://stackoverflow.com/questions/6954479/emacs-tramp-doesnt-work
Essentially in your .bashrc
case "$TERM" in
PATH vs exec-path
The PATH environment variable lists directories for programs to find executable files (when executing a non-absolute filename). The exec-path Emacs variable lists directories for Emacs to find executable files (again, when executing a non-absolute filename). The value of exec-path takes its value from the environment variable PATH when ...
It looks like you've run the exec-path-from-shell from a Tramp buffer, so when it runs the shell, it attempts to do its magic on the remote server and then set the environment variables in your local emacs instance. That's almost certainly not what you want, and it's not a case that exec-path-from-shell is designed for. It looks like it's Tramp or your Tramp ...
exec_path is initialized from the EMACSPATH and PATH environment variables. Emacs also adds the directory containing the emacs binary to the end. This is done at startup by init_callproc_1 in callproc.c (http://git.savannah.gnu.org/cgit/emacs.git/tree/src/callproc.c#n1466)
The systemd.exec man page has a section about the environment variables it sets ...
You should remove :defer f, because you don't want exec-path-from-shell to be defer loaded and you are going to use function from it when Emacs starts. Try something like the following
:if (memq window-system '(mac ns x))
(setq exec-path-from-shell-variables '("PATH" "GOPATH"))
Ok, solved this one. It turns out that there was an export PATH in my .bashrc (as well as .bash-profile). exec-path-from-shell doesn't like this, and only wants that export to happen in .bash-profile. This warning message gives a hint of the expectation. But I didn't realize that the package doesn't work if the condition isn't satisfied.
This looks like a standard case for exec-path-from-shell.
Essentially, the emacs environment is dependent on where it was started from (e.g. GUI app vs terminal vs daemon, etc.) This package loads your real shell and copies the values into emacs.
Your call to setenv will only change the environment in shells that are called later and not your current shell.
So the correct way is put the correct setenv in your init file(s) and then when you call eshell you will get the correct values.
As to why a normal shell finds it and emacs does not that depends on what OS you are on and how you call emacs and ...
The C function set_initial_environment in callproc.c populates process-environment and initial-environment together. Subsequent calls to setenv are the usual way of modifying process-environment (but noting that it's very common to be doing that in only a temporary dynamic scope). Obviously it's just a list though, so other manipulations are also entirely ...
exec-path is where subprocesses find executable files. so your emacs should be able to find the executable. However, require is looking not for the executable, but for hindent.el (or the coresponding compiled file hindent.elc) which is the emacs lisp interface to hindent. You have to modify load-path for that (or put hindent.el in one of the directories that ...
Apparently the .profile file is only supposed to be read on login
Correct. Invariably there are other shell resource files which are read on non-login shell invocations, however.
If your shell is bash then you can use ~/.bashrc for this, and including something like the following in your ~/.profile is then fairly common if you want your non-login settings ...
Old question, new answer...
I was in the same position, and met success following the advice in 1 to install the package
exec-path-from-shell and add to my ~/.emacs.d/init.el
For me, this solution was necessitated by not having any other means than systemd to get an emacs --daemon to reliably ...
If the problem is your fancy custom prompt in the remote shell, an easy workaround is to add to your .bashrc or equivalent:
if [[ $TERM == "dumb" ]]; then
export PS1="$ "
After you define your PS1.
Note 1: the credit goes to ChasingLogic as this is their suggestion in this thread.
Note 2: I also posted this answer there.
I ran into this problem, and the issue wasn't PS1--it had something to do with iterm's shell integration. The theory in this iterm2 bug report is that the escape characters used by the shell integration are confusing emacs.
A recent (not yet released) commit to the code disables shell integration for dumb terminals.
Before I saw that fix, I just changed ...
For future searchers: I used this to solve the problem:
It is a small elisp module that mimics the behavior of the /usr/libexec/path_helper
utility available on MacOS.
I added these lines to my .emacs
;; set path correctly on MacOS, based on /etc/...
Load library Dired+ (`dired+.el).
Use this command:
;; Change ROOT definition if you want a different Windows drive as root.
;; (Windows does not have a single root.)
(defun foo (regexp)
"Append the accessible directories that match REGEXP to `exec-path'.
You are prompted for the REGEXP."
(interactive (list (read-regexp "Regexp: ")))