Bash completion seems to work correctly for the PATH that is set when I start emacs, but if I change the PATH in an emacs shell buffer, I cannot seem to get Emacs to rethink its list of possible completions.
Is there some way to reinitialize Emacs view of the completions?
In a non-emacs shell, everything works as expected with the occasional hash -r thrown in for good measure.
Assuming you are using completion-at-point, there is a variable exec-path that maintains a list of the directories that are searched for executables. shell-command-completion, which is by default part of shell-dynamic-complete-functions, searches those locations.
You can update that variable with new locations to search for executables, eg. (push "<new-directory>" exec-path).
Related
I'm somewhat new to gnu emacs, and so perhaps this is a noob question, but I have a few batch files I use a lot when coding in emacs to compile/build/execute/debug/etc. I am wondering how I could A) run these batch files from emacs without having to keep opening a cmd prompt window or going to windows explorer and B) bind this to a key shortcut (perhaps I could specify the file?) I have seen several things online about running emacs in batch-mode, but I don't believe this is what I'm looking for. And I know it is possible because I have seen others run batch from emacs (output and everything would appear in a new buffer adjacent to the current as if you did C-x 3)
Thanks in advance!
To run an arbitrary shell command in Emacs, you call shell-command which is bound to M-!
See C-hf shell-command (or C-hkM-!) for details.
I believe in the Windows-native Emacs, the default shell is cmd (or some alias thereof), so I'm reasonably confident that this is what you're thinking of.
I'm not sure whether all of the following work in Windows, but related commands are:
M-& - async-shell-command
M-| - shell-command-on-region
And with a prefix argument (e.g. C-uM-!) any of those commands will insert the shell command's output into the current buffer. (In the case of shell-command-on-region, that replaces the region.)
In native emacs on windows, how can I specify environment variables for launching my shell inside emacs without modifying emacs' environment? In my specific case I'd like to set HOME to a cygwin-specific value for zsh without modifying where emacs thinks it's config file lives.
I've tried some things like changing my shell to env -u HOME ...\zsh.exe, but that seems to break (shell-command) (it appeared to involve argument order).
If this command existed, it would probably do what I want:
(setq explicit-zsh-environment '("HOME" nil))
I've read a bunch of related questions like (How can I run Cygwin Bash Shell from within Emacs?), but the unusual part for me is that all my config files are cygwin-ln-ed or windows-mklink-ed into a git repo and cygwin and windows take very different and incompatible approaches to symlinks.
Is this about running zsh as a shell inside Emacs (i.e. not about starting Emacs from a zsh shell), and having the environment that the inferior zsh process sees be different to the environment that Emacs has?
If so, you can bind the C-hv process-environment variable when you start a process. e.g.:
(let ((process-environment '("HOME=/tmp")))
(call-interactively 'shell))
$ echo $HOME
/tmp
From the Emacs manual:
Emacs sends the new shell the contents of the file ~/.emacs_shellname as input, if it exists, where shellname is the name of the file that the shell was loaded from. For example, if you use bash, the file sent to it is ~/.emacs_bash. If this file is not found, Emacs tries with ~/.emacs.d/init_shellname.sh.
So for zsh you would put inside ~/.emacs.d/init_zsh.sh something like:
export HOME=/tmp
I have noticed that my shell buffers in Emacs (24.3.1) have (an extra) ".:" at the beginning of the $PATH variable on my Mac OS X (but not on my linux laptop that has the same . files), compared to my regular shell, which has it in the middle somewhere. Is this just me, or does Emacs on mac do this for some purpose? And can I prevent it? I don't think it has caused any actual problems, but it does cause warnings from RVM, and theoretically it has risks.
Thanks!
According to the emacs help entry for the shell command, the started shell gets the file ~/.emacs_SHELLNAME or ~/.emacs.d/init_SHELLNAME.sh as first command list (if one of those files exist). So you can modify the value of the PATH environment variable in one of those two files, but you should then check that your shell (configurable with the explicit-shell-file-name variable, the ESHELL environment variable or the shell-file-name variable, in that order) does not ignore commands that are issued during start-up.
Another reason may be that your (system-wide) configuration includes the current directory into the PATH value (you can check that with echo $PATH in a terminal), thus you would have to reconfigure your shell instead of emacs.
Considering security, having the current directory in the PATH does have the risk of unintentionally executing the wrong program (eg.: you have a self-written program named test and want to execute /usr/bin/test). That may cause some serious trouble, if that happens while working with super-user privileges.
Two little questions with regards to the configuration of Eshell. I looked at the customization options and even the source code, but to no avail. Maybe I should have taken a better look.
When I start Emacs and open Eshell, the directory is '~/.emacs.d/elpa' instead of my home directory '~/’, what I would expect. I have no idea, where this configuration comes from, and did not find a way to change it.
I changed $PATH in my .bashrc and I customized the Emacs variable 'exec-path' to my needs. However, the first change is not reflected by Eshell, it does not know about it, while bash does. How does Eshell get this information, and how comes it differs from bash in its knowledge about changes in this variable?
Thanks for any hints
Thorsten
PS
I found a similar question [here] (http://stackoverflow.com/questions/3621755/what-setup-file-does-eshell-elisp-shell-read-when-it-starts-how-eshell-sets-i). The answer to point 2. is that eshell does not read .bashrc, therefore $PATH must be set in a file that is read earlier in the start-up process. On my Ubuntu system
/etc/environment
seems to be the file that is read by Emacs on start-up to set $PATH.
eshell seems to start in the current working directory, which for you (right after Emacs started) is "~/.emacs.d/elpa". You can change it manually with "M-x cd", but that shouldn't be necessary. If you edit some file and start eshell from its buffer, eshell will start in the same directory as the file.
But if you really want to start every eshell session in your home directory, you can make a hook call "cd" before eshell starts.
As already mentioned for Q1: eshell starts up in the directory of the current buffer when eshell is started. If I recall correctly (which is NOT a given), on macOS for a short period of time, when emacs was started by the Finder (i.e. double clicking the icon), the current buffer for *scratch* was root /. Now, when it is started by the finder, the current buffer for *scratch* is my home directory.
For Q2: the variable that you want to set is eshell-path-env. This is a colon separated list of paths.
I'm already using .dir-locals.el to set directory specific variables so I plan to do it that way but I'm sure there are start up hooks that you can use.
Remember that eshell is not bash, zsh, csh, etc. It is not ever going to read their rc files nor does it read /etc/environment, etc. Unlike comint-mode derivatives, it is not a subprocess of emacs but is wholly contained within emacs.
I found Mastering Eshell to be extremely helpful.
I'm trying to get a compile command (rake cucumber) to run with a specific ruby version on my Mac OS X system, I use rvm to do this currently in the terminal. My ~/.MacOSX/environment.plist has the correct path in it, but emacs insists on prepending to this path and therefore making it useless. I've also tried:
(when (equal system-type 'darwin)
(setenv "PATH" (concat "/Users/fearoffish/.rvm/bin:/Users/fearoffish/.rvm/rubies/ruby-1.8.7-p249/bin:/Users/fearoffish/.rvm/gems/ruby-1.8.7-p249/bin:/Users/fearoffish/.rvm/gems/ruby-1.8.7-p249%global/bin:/Users/fearoffish/.rvm/bin"))
(push "/Users/fearoffish/.rvm/bin" exec-path)
(push "/Users/fearoffish/.rvm/rubies/ruby-1.8.7-p249/bin" exec-path)
(push "/Users/fearoffish/.rvm/gems/ruby-1.8.7-p249/bin" exec-path)
(push "/Users/fearoffish/.rvm/gems/ruby-1.8.7-p249%global/bin" exec-path)
(push "/Users/fearoffish/.rvm/bin" exec-path))
It was the desperate attempt of an emacs beginner to get what I wanted. It still prepends in front of it, so my path ends up being:
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Users/fearoffish/.rvm/bin:/Users/fearoffish/.rvm/rubies/ruby-1.8.7-p249/bin:/Users/fearoffish/.rvm/gems/ruby-1.8.7-p249/bin:/Users/fearoffish/.rvm/gems/ruby-1.8.7-p249%global/bin
I don't want /usr/bin and others prepending, I want my path first and the emacs prepended path to be at the end, I reckon this would fix my problem.
I test this by simply opening Aquamacs and running meta-x compile and then echo $PATH.
Any ideas?
A small modification to the solution by sanityinc (couldn't find a way to enter it in the comments above -- is that just me?)
I use -l option to the shell to force a login shell (which reads .profile or .bash_profile), rather than an interactive shell (which only reads .bashrc).
I do some string trimming on the returned path (as inspection shows a newline sneaking in).
Modified code:
(defun set-exec-path-from-shell-PATH ()
(let ((path-from-shell
(replace-regexp-in-string "[[:space:]\n]*$" ""
(shell-command-to-string "$SHELL -l -c 'echo $PATH'"))))
(setenv "PATH" path-from-shell)
(setq exec-path (split-string path-from-shell path-separator))))
(when (equal system-type 'darwin) (set-exec-path-from-shell-PATH))
Everyone seems to have misunderstood the original issue: the path is already setup correctly in Emacs, and the correct path is already passed to the shell started by the compile command! So what gives? Here is the answer:
In MacOS X, there is a small tool called path_helper(1). It is called by default from /etc/profile, which is executed by Bash on shell startup. When you start a compilation from Emacs, it launches a shell (which by default is Bash on MacOS X), and therefore executes this path_helper tool. And here comes the key point: path_helper rearranges your path, moving the standard directories like /usr/bin in front of your custom added directories, no matter where you originally added them. Try this yourself by opening a shell and first having a look at what PATH is, and then execute /usr/lib/path_helper and have look at the resulting PATH!
The brute force solution for you might be to simply comment out the call to path_helper in /etc/profile. Note however that then you won't automatically get the paths in /etc/paths.d setup by path_helper, which is the tool's main purpose.
I don't have a Mac, so I cannot test this directly, but this can all be found in the *info* page Interactive Inferior Shell.
When you start a shell in Emacs, the process that gets spawned is the program in the Emacs variable explicit-shell-file-name (and if that is nil, the environment variables ESHELL and SHELL are used).
It then sends the contents of ~/.emacs_*shellname* (e.g. if your shell is csh, then ~/.emacs_csh would be sent over. Also, the appropriate .rc files for csh program is sourced, so you can update that as well (in my case .cshrc). Additionally, you can wrap customizations in the .rc file with a check for the environment variable INSIDE_EMACS (which which Emacs sets before it runs a shell).
You need to update those files to change the path in the shell, not the Emacs variable exec-path. exec-path - which is just a list of directories Emacs uses to find executable programs. The behavior of the executables are not affected by changes to exec-path.
I find the environment.plist scheme on Macs pretty ugly, so I use the following snippet, which assumes you want Emacs to use the same PATH that you see in your Terminal.app:
(defun set-exec-path-from-shell-PATH ()
(let ((path-from-shell (shell-command-to-string "$SHELL -i -c 'echo $PATH'")))
(setenv "PATH" path-from-shell)
(setq exec-path (split-string path-from-shell path-separator))))
(This works for me in Emacs 23; haven't tried it in other versions, but I'd expect it to work.)
try this maybe. replace path string with yours.
(add-to-list 'load-path "~/opt/swank-clojure/src/emacs")
As far as I observed, Emacs takes the path variable from the shell it is launched from, so one solution is to change $PATH in the shell before you launch Emacs.
One other approach I used, which is more flexible, is to use a Makefile and append a "source ~/script_that_set_path" in front of each make commands you have.
I have tried so many different approaches to this that ended up not using emacs to setup my compilation command environment.
What I do now is to create a run_helper.sh file that simply initializes a clean environment and then uses exec $* to execute the command passed as argument to run_helper.sh
This run_helper.sh is usually project specific, but I keep a template which I use to start with when I create a new project.
Then I simple run compile from emacs like bash run_helper.sh rspec path/to/tests for example.
If I am using this to run ruby tests, my helper initializes RVM to use the proper ruby and gemset. If I am using some other language it may just export required environment variables or perform some other initialization, but this way I can do it in bash script instead of always having to mess with emacs paths and elisp every time I start a new project.
Here's an example of a run_helper.sh file
#!/bin/bash
cd /Users/simao/Documents/sp
export DYLD_LIBRARY_PATH="/usr/local/mysql/lib:$DYLD_LIBRARY_PATH"
source "$HOME/.rvm/scripts/rvm" # This loads the proper ruby and gemset from .rvmrc
export RAILS_ENV=test
exec $*
This also makes my tests run faster because I have lots of stuff in my .zshrc that I don't want to load just to run some tests.
It worked for me with two things.
First I followed sanityinc advice
An improved and modified version of the code snippet is now published as elisp library called exec-path-from-shell; installable packages are available in Marmalade and Melpa
I still had a problem with compile commands. Valko Sipuli is right there was a problem involving path_helper.
I commented the corresponding line in /etc/profile and it did not help. Problem still there.
I don't use bash but zsh. Digging a little I found /etc/zshenv. This file also calls path_helper.
After commenting the path_helper section in /etc/zshenv my path is finally correct