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
Related
Can I have certain settings that are universal for all my users?
As well as /etc/profile which others have mentioned, some Linux systems now use a directory /etc/profile.d/; any .sh files in there will be sourced by /etc/profile. It's slightly neater to keep your custom environment stuff in these files than to just edit /etc/profile.
If your LinuxOS has this file:
/etc/environment
You can use it to permanently set environmental variables for all users.
Extracted from: http://www.sysadmit.com/2016/04/linux-variables-de-entorno-permanentes.html
man 8 pam_env
man 5 pam_env.conf
If all login services use PAM, and all login services have session required pam_env.so in their respective /etc/pam.d/* configuration files, then all login sessions will have some environment variables set as specified in pam_env's configuration file.
On most modern Linux distributions, this is all there by default -- just add your desired global environment variables to /etc/security/pam_env.conf.
This works regardless of the user's shell, and works for graphical logins too (if xdm/kdm/gdm/entrance/… is set up like this).
Amazingly, Unix and Linux do not actually have a place to set global environment variables. The best you can do is arrange for any specific shell to have a site-specific initialization.
If you put it in /etc/profile, that will take care of things for most posix-compatible shell users. This is probably "good enough" for non-critical purposes.
But anyone with a csh or tcsh shell won't see it, and I don't believe csh has a global initialization file.
Some interesting excerpts from the bash manpage:
When bash is invoked as an interactive
login shell, or as a non-interactive
shell with the --login option, it
first reads and executes commands from
the file /etc/profile, if that file
exists. After reading that file, it
looks for ~/.bash_profile,
~/.bash_login, and ~/.profile, in that
order, and reads and executes commands
from the first one that exists and is
readable. The --noprofile option may
be used when the shell is started to
inhibit this behavior.
...
When an
interactive shell that is not a login
shell is started, bash reads and
executes commands from
/etc/bash.bashrc and ~/.bashrc, if
these files exist. This may be
inhibited by using the --norc option.
The --rcfile file option will force
bash to read and execute commands from
file instead of /etc/bash.bashrc and
~/.bashrc.
So have a look at /etc/profile or /etc/bash.bashrc, these files are the right places for global settings. Put something like this in them to set up an environement variable:
export MY_VAR=xxx
Every process running under the Linux kernel receives its own, unique environment that it inherits from its parent. In this case, the parent will be either a shell itself (spawning a sub shell), or the 'login' program (on a typical system).
As each process' environment is protected, there is no way to 'inject' an environmental variable to every running process, so even if you modify the default shell .rc / profile, it won't go into effect until each process exits and reloads its start up settings.
Look in /etc/ to modify the default start up variables for any particular shell. Just realize that users can (and often do) change them in their individual settings.
Unix is designed to obey the user, within limits.
NB: Bash is not the only shell on your system. Pay careful attention to what the /bin/sh symbolic link actually points to. On many systems, this could actually be dash which is (by default, with no special invocation) POSIXLY correct. Therefore, you should take care to modify both defaults, or scripts that start with /bin/sh will not inherit your global defaults. Similarly, take care to avoid syntax that only bash understands when editing both, aka avoiding bashisms.
Using PAM is execellent.
# modify the display PAM
$ cat /etc/security/pam_env.conf
# BEFORE: $ export DISPLAY=:0.0 && python /var/tmp/myproject/click.py &
# AFTER : $ python $abc/click.py &
DISPLAY DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}
abc DEFAULT=/var/tmp/myproject
I've got a makefile for installing my personal repo of config files, part of which is compiling my emacs scripts:
compile:
emacs -batch --eval "(progn (load \"~/.emacs\") (byte-recompile-directory \"~/.emacs.d\" 0))"
The problem is, on OSX, I have an alias called "emacs" that points to the Emacs.app binary for use in a terminal, this is defined in my ~/.bash_profile.
Now, no matter what I do, I can't seem to get the shell that Make is calling to read a startup file to load that alias, so that compilation step always fails.
Does anyone know how to do this?
.bash_profile is only read by interactive login shells. Exported environment variables set in it are inherited through the process environment, which means that these settings are generally available to all programs the user starts (if bash is indeed the login shell, of course).
No such inheritance happens for aliases, though. Bash supports exported functions, but that's an obscure feature which can easily break other programs (for example, those which assume that environment variable values do not contain newlines). If you go that route, you may have to use .bashrc instead, to make sure that these functions are exported by interactive bash shells which are not login shells.
I expected the easiest solution is to put a directory like $HOME/bin on the PATH (in .bash_profile or .bashrc, whatever works best) and put an emacs wrapper script into that directory which invokes the actual binary using exec /path/to/Emacs.app "$#" (or maybe just a symbolic link would do).
That is very strange. Aliases are not exported to sub-shells, and the .bash_profile script is only run by interactive shells: make doesn't invoke an interactive shell (by default). So, it's hard to understand how the shell make invokes would see that alias based on the information you've provided.
Maybe you set the BASH_ENV shell variable somewhere? You should never do that, unless you really know what you're doing.
Maybe you reset make's .SHELLFLAGS variable to force a login shell? You shouldn't to that either.
Anyway, you can try using command which avoids aliases etc. Unfortunately make doesn't know this is a shell-built in, so you have to convince it to run a shell. This will be fixed in the next release of GNU make but Apple will never ship that.
compile:
command emacs -batch --eval "(progn (load \"~/.emacs\") (byte-recompile-directory \"~/.emacs.d\" 0))" && true
I have emacs as my defualt editor in linux, and I also have alias in my .cshrc file.
alias e "emacs -mm"
Sometime I just want to hit the file name in the command line and open it in emacs directly with out the editor beign metioned.
Example instead of
$ e foo.cc&
What I want is to open
$foo.cc
May be this is lazy to do but it saves a lot time if you have so many files to handle. Thanks for the help.
You probably cannot open a file with $foo.cc (and that would be ambiguous for a shell script script.sh: would script.sh means "edit the file script.sh" or "run the shell script script.sh" ?). However,
You might want to use xdg-open, or the $EDITOR variable (see environ(7)). If you always have a single emacs running, you might set EDITOR to emacsclient in your ~/.bashrc (if using /bin/bash) or your ~/.zshrc (if using /bin/zsh)
BTW many editors (including emacs, gedit, vim) are able to edit several files, i.e. $EDITOR *.c
And depending upon your login shell (zsh, fish, or bash) you could set up a shell function or alias to simply type e foo.c; I feel that it is not worth the effort, since with autocompletion I just have to type 3 keys e m tab to get emacs (and often the up arrows are enough)
Actually I start only once every day emacs then open many files inside it (and also I compile inside emacs)
BTW, you should avoid csh since it is considered harmful. Install a good interactive shell (e.g. with sudo aptitude install zsh zsh-doc) and use once chsh(1) to make it your login shell.
I installed emacs in ubuntu (using sudo apt-get install emacs). I am havine the problem that when I try to run a shell command from within emacs (for example M-! ls) the output is preceded by this:
bash: cannot set terminal process group (-1): Invalid argument
bash: no job control in this shell
In my .emacs I have the option (setq shell-command-switch "-ic") . This is so that I can presumably use my aliases as well as commands. This has not given me issues at work and it lets me use my aliases. How can I use my aliases but avoid this problem?
I guess that by setting your shell-command-switch like that, you are executing code paths in your .profile or system profile which depend on job control in shells.
I would fix this error by defining the aliases you need in the correct code paths so that that appear in shells which are not started with -i
You could try to swap -i with --rcfile .aliases or something similar so that alias in emacs does not differ from alias in your login shells. If your .bashrc has important stuff for your work, create a file like .bashrc.emacs with the content
source .bashrc
source .aliases
and point to that file with --rcfile .bashrc.emacs in your (setq) instruction.
Where did you define your aliases? Ubuntus .bashrc reads .bash_aliases and that should happen also to non-interactive shells.
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