Is there a way to sync windows environment variables with Cygwin?
For example, in CMD echo %inetroot% gives the path to a project build. Is it possible to transfer this env variable to Cygwin such that echo $inetroot provides the same path?
Thanks!
Use the env program to so that ... or echo "$inetroot". I think the variable names are case-sensitive, though (in Bash and thus MinGW).
Those variables are all available in MinGW from Windows (user profile and global). Again, use env to list them or for example env|grep -i inetroot to find the properly capitalized version of the variable name.
Related
I am trying to set an environment variable for Bash. However, I need this to be set before any of the shell's startup scripts (including /etc/profile), because /etc/profile acts differently based on the value of this variable.
Specifically, I want to create a shortcut to MinTTy that works like git-bash, but I need to set the MSYSTEM environment variable before the shell starts, or at least before it starts processing any startup scripts.
A solution that has MinTTy setting the environment variable before it starts the shell will also be accepted.
Edit:
What I am really looking for is sort of a command-line option to BASH that will set an environment variable, somewhat akin to the -D option to most C (and other) compilers. This would be a "general case" solution. Alternatively, a similar option (command line or configuration) to MinTTy will also do the job.
For my specific need, I have an idea for a potential work-around: Run a BASH script - with no startup scripts - that sets my required variable and execs another shell as a login shell.
Define the target of your shortcut file as follows:
C:\cygwin64\bin\mintty.exe /bin/bash -l -c "MSYSTEM=MINGW64 exec -l bash"
This command:
invokes bash directly as a login shell (-l)
passes it a command (-c) that defines the environment variable of interest (MSYSTEM=MINGW64) and then invokes a new copy of bash (exec -l bash), which inherits the existing environment, plus the new definition, but sources the profile(s) again, due to -l
(and prepends - to the executable name reported in $0 (-bash), as would happen if you started Mintty with just -, which is what the regular Cygwin64 Terminal shortcut does).
An alternative is to set the environment variable in Windows first.
[Not an option for the OP] If the environment variable should always have the same value, set it persistently as follows: run sysdm.cpl, go to the Advanced tab, click on Environment Variables... and define variable MSYSTEM as needed.
To define the variable ad-hoc, create a batch file as follows and make the shortcut target that batch file:
#echo off
# Define the env. variable with the desired value.
set "MSYSTEM=MINGW64"
# Invoke Mintty with a login shell, which will now see the env. variable.
# Adjust the path to mintty.exe as needed.
c:\cygwin64\bin\mintty.exe -
Note: Opening the batch file from a shortcut briefly opens a regular console window before opening Mintty, which may be undesired.
A simple helper WSH script, as demonstrated in this answer of mine, can prevent this.
You should just be able to do the same as you do in command prompt. Therefore, you can do:
set VAR=VarContents
Although I already accepted an answer above, I found this link that specifically addresses the second part of my question (Mintty specific) or an alternative way of setting an environment variable before running a command.
The contents of the Windows shortcut can be:
C:\cygwin64\bin\mintty.exe -t "Title" /bin/env "MSYSTEM=MINGW64" /bin/bash -l
(Suggested by Mintty Tips:Setting environment variables.)
I've installed a series of binaries which appear in usr/local/bin on my MACOSX (They're called DCMTK). The usr/local/bin folder appears on the path as expected:
PATH=/Users/jim/Library/Enthought/Canopy_64bit/User/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/local/git/bin:niftyreg_install/bin
I can run these commands as expected from any folder in a Terminal window, however I can't seem to run any of them from within Matlab (2014b) using the command:
cmd=['dcmdump -h'];
system(cmd)
/bin/bash: dcmdump: command not found
Running 'env' in a Terminal shows that I am using the same SHELL as Matlab:
SHELL=/bin/bash
My question is why is it when Matlab invokes bin/bash it is not finding the binaries in usr/local/bin? Is there something in .bash_profile I need to update?
Thanks,
Jim
As Mark Setchell already pointed out in his comments, you can echo the PATH variable from within MATLAB using
cmd=['echo $PATH'];
system(cmd);
You can also get environment variables, such as $PATH using the MATLAB getenv function:
getenv('PATH');
As you also posted in comments, in your case /usr/bin/local is missing in the $PATH variable. MATLAB has an option to set environment variables via the setenv function. But watch out: This sets the variable to only the specified value. To append a folder, you have to query the existing variable and append a folder to that:
setenv('PATH', [getenv('PATH'),':','/usr/bin/local']);
As separator, either ; (for Windows systems) or : (for Unix based systems) is used. In the example above I added : as you are working with Mac OS X.
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 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 know how to retrieve a normal machine wide environment variable in CMAKE using
$ENV{EnvironmentVariableName}
but I can not retrieve a user specific environment variable. Is it possible and how?
Getting variables into your CMake script
You can pass a variable on the line with the cmake invocation:
FOO=1 cmake
or by exporting a variable in BASH:
export FOO=1
Then you can pick it up in a cmake script using:
$ENV{FOO}
You can also invoke cmake itself to do this in a cross-platform way:
cmake -E env EnvironmentVariableName="Hello World" cmake ..
env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...
Run command in a modified environment.
Just be aware that this may only work the first time. If CMake re-configures with one of the consecutive builds (you just call e.g. make, one CMakeLists.txt was changed and CMake runs through the generation process again), the user defined environment variable may not be there anymore (in comparison to system wide environment variables).
So I transfer those user defined environment variables in my projects into a CMake cached variable:
cmake_minimum_required(VERSION 2.6)
project(PrintEnv NONE)
if (NOT "$ENV{EnvironmentVariableName}" STREQUAL "")
set(EnvironmentVariableName "$ENV{EnvironmentVariableName}" CACHE INTERNAL "Copied from environment variable")
endif()
message("EnvironmentVariableName = ${EnvironmentVariableName}")
Reference
CMake - Command Line Tool Mode
You need to have your variables exported. So for example in Linux:
export EnvironmentVariableName=foo
Unexported variables are empty in CMAKE.
Environment variables (that you modify using the System Properties) are only propagated to subshells when you create a new subshell.
If you had a command line prompt (DOS or cygwin) open when you changed the User env vars, then they won't show up.
You need to open a new command line prompt after you change the user settings.
The equivalent in Unix/Linux is adding a line to your .bash_rc: you need to start a new shell to get the values.