I have this need to let Emacs recognize all the shell environment variables.
The current setup:
I use VirtualBox and launch Emacs there to remotely access server files via the Tramp mode. When i do c-x c-f, and type
$RESOURCE_HOME/foo.bar
Emacs can't recognize this path, even if this is a valid path on the server -- $RESOURCE_HOME is a self-defined var.
I know this question's been answered there: How do I make Emacs recognize bash environment variables for compilation?
But there are so many self-defined variables that I don't want to write them manually.
I wonder if it's possible to solve it in a better way.
NOTE: i'm using Tramp mode, so please clarify your ideas saying vbox machine vs. server machine. Thanks!
Emacs already lets you use envvars like you suggest above. So your problem is that those vars aren't defined in Emacs's environment. Most likely it's because you define those vars in your shell's init file but that you start Emacs from a context where the shell hasn't been involved so those init files haven't been started yet.
If so, a simple fix is to start Emacs from a shell.
Related
I cannot use vcvarsall.bat from cygwin because cygwin overwrites environment variables (like PATH) and then the environment in cmd.exe, which is inherited from the cygwin BASH environment, finds the wrong cmake.exe.
Is there any pre-defined way to do this? Maybe without having to resort to opening a new shell window? Currently, I'm rewriting and stripping the entire PATH string. But now I have another issue: TEMP points to the wrong directory. I could just change that manually, but I really want it to adhere to original Windows behaviour.
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
Is there a possability in Emacs to run custom commands or a set of commands (eg. shell) with a user defined emacs shortcut/hook?
To make this clearer. I am working with an embedded system (target), but developing on the host. After writing and compiling code (eg using emacs compile command), I would like to copy (eg. scp) the binary to the system right away.
Furthermore it would be good if the custom shorcut/hook would be easy to adjust (eg. ip address of the target).
Btw: I am aware of the "shell-command" in emacs, but that is not quite what I am looking for.
Would appreciate any advice. Thanks!
I ended up using C-x C-f /root#my-target-ip:/tmp/myfile to edit the file directly on the target. Then you can run it with shell-command ./myfile from within emacs.
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.
I would like to know if there is a (simple) solution to the following issue:
When I log in with ssh to a specific host, I would like to automatically execute a (bash)script on that host. This way I could -for example- load my aliases on that host.
Definitively the bashrc script is not executed; The ssh configuration files do not seem to help in this issue either.
Any suggestions?
Thanks in advance!
BTW: The host is running on Gentoo
If .bashrc isn't being run, try .profile, which has a similar function. Different shells use different startup scripts at different times, so knowing when to run things is useful.
On many systems where you have a choice of which shell to use, you are put through ~/.profile only. This way there is no need to find out (and no probably wrong guessing) which shell you're running in and which profile to actually load (.bashrc, .cshrc, .kshrc etc.) and which ones to avoid loading.
The easiest solution in your case would be to create a link (a symbolic one if you prefer visibility) to your favourite shell's startup script as in ln -s ~/.bashrc ~/.profile. If you don't intend to ever using anything other than bash, you're set.