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.
Related
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.
In a makefile, I have the following:
SHELL = $(SOME_DIRECTORY)/sh
showme:
echo $(SHELL)
This is on MS Windows. The situation is that make is in the PATH (or is being directly invoked) but an acceptable shell (i.e. sh.exe) is NOT in the PATH. Neither is it an option to globally modify the PATH variable to include a sh.exe (too much potential conflict between Cygwin, msysgit, and more). Therefore, make defaults to using the Windows cmd.exe command processor, which is hardly ideal.
It is an option to set a system-wide environment variable other than PATH however. So I had the bright idea of putting a path to the directory containing sh.exe in SOME_DIRECTORY and then using it in the SHELL variable in the makefile. But it's not working for some frustrating reason:
make
echo sh.exe
sh.exe
If I use any other variable than SHELL and echo it, then it prints the expected result. But of course that doesn't have the desired effect of changing the shell.
What am I missing here? What do I need to do to have an environment variable with a custom user-specified name (i.e. not SHELL, PATH, etc.) affect the shell used by make?
Which make are you using? GNU make (gmake) 3.82 is most common and it should work in the way you expect. As MadScientist notes, gmake behaves differently under windows wrt SHELL.
You should be able to set SHELL to the full path of an existing executable file, and gmake will use it to execute commands.
However: if SHELL is not set OR if it is set to a non-existent file, gmake will use the value of ComSpec (mind the caps) as the shell.
Is there an exe at the test path you're using? So $(SOME_DIRECTORY)/sh is an existing exe? (Note that you can omit the '.exe' and gmake will supply it for you, but the file must exist)
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 have been trying to setup a environment variable in Cygwin using the command export PRIMOSBASE=/directory/for/primosfiles.
And when i check the variable using the command echo $PRIMOSBASE it shows the /directory/for/primosfiles. hopeful this means the environment variable is set.
But when i try to run a shell script(primos) for the /directory/for/primosfiles, it shows
./primos: line 8: /prilaunch.pl: No such file or directory
chmod: failed to get attributes of `step1.sh': No such file or directory
which means i have not set the PRIMOSBASE environment. could anyone please tell me where i am going wrong...
Thanks ...
Run
echo "export PRIMOSBASE=/directory/for/primosfiles" >> ~/.bashrc
to append the command to the end of your .bashrc file, so that the variable is set each time you use Cygwin. Then run
source ~/.bashrc
to make it take effect immediately.
NOTE: Make sure you use double brackets (>>) to append. It might be a good idea to make a backup of .bashrc just in case. If you're not comfortable with I/O redirection, an alternative is to edit .bashrc with an editor. I think vim is among the default tools in Cygwin.
I had a similar issue trying to get ANDROID_HOME to work in a Cygwin window. When I used the linux path separators, as follows
ANDROID_HOME=/cygdrive/c/Users/User/AppData/Local/Android/sdk my gradlew build script complained it couldn't find the sdk in ANDROID_HOME.
I eventually discovered that I had to set my environment variable in the Windows format, including Windows path separators '\', as follows
ANDROID_HOME=C:\Users\User\AppData\Local\Android\sdk
Note: the PATH and several other environment variables set in Windows are converted into Linux format. I hope this helps others who want/need to use Cygwin + Windows + essentially Windows programs that need environment variables.
I am writing installation in a Makefile in which I need to set the PATH env. variable.
In the windows part of it, I found the following:
set: With set PATH="%PATH%;%CD%" I can change the PATH inside the running environment. There are two problems with this:
The environment is a spawned cmd.exe by make which gets its variable affected and the effect removed as soon as it closes
Even if the previous problem could be solved, still the cmd.exe that calls make would close one day and the modified PATH lost.
setx: A microsoft tool that can permanently change env. variables. According to microsoft itself, this is the only command-line option to do this. Using setx PATH "%PATH%;%CD%" -m however, turns path into the literal %PATH%;%CD% and doesn't replace the variables by their contents!
Note that I am calling make from cmd.exe not cygwin or other modified windows shells that act more like linux. What I'm saying is that, although I can use $(PATH) in my makefile (instead of %PATH%), I can't use pwd (instead of %CD%)
Also note that if in cmd itself I run:
setx PATH "%PATH%;%CD%" -m
it works perfectly. Somehow I need to make make execute this command.
Do you have any idea how to fix this, or what workaround do I have?
P.S. Just for the record, echo "%PATH%;%CD%" in the Makefile also echoes the literal "%PATH%;%CD%" rather than let cmd.exe handle it
Back in the day i Borland C++ Free Command Line tools included a version of make which played well with the dos/windows command line. Probably still floating around somewhere.
Workaround:
Create a .bat file, put the command there, and invoke it from the Makefile.
I still am interested in a direct fix in the Makefile though.