I have this project that has a makefile, which sets the pythonpath to the current directory using PYTHONPATH=$(shell pwd). But I know that the way used is applied only in linux. The way to dodge that is by using a linux os or wsl ubuntu terminal, but I want to dodge all of that. So the full part in the makefile is:
CONFIG_PATH=./experiments/configs/
CONFIG_NAME=seld.yml
OUTPUT=./outputs # Directory to save output
EXP_SUFFIX=_test # the experiment name = CONFIG_NAME + EXP_SUFFIX
RESUME=False
GPU_NUM=0 # Set to -1 if there is no GPU
.phony: train
train:
PYTHONPATH=$(shell pwd) CUDA_VISIBLE_DEVICES="${GPU_NUM}" python experiments/train.py --exp_config="${CONFIG_PATH}${CONFIG_NAME}" --exp_group_dir=$(OUTPUT) --exp_suffix=$(EXP_SUFFIX) --resume=$(RESUME)
If I want to have the same effect but on windows, how should it be edited?
I have searched for this, but there is nothing much useful that I found. All the answers found was for linux. I know that I can set the pythonpath on windows in the system environment variables, but I don't know how should the line change in that case? And whether or not adding the pythonpath to my system environmnetal variables is the thing to do or not?
GNU Make has the built-in variable CURDIR which has the absolute path to current working directory: PYTHONPATH=$(CURDIR).
But you could instead provide it as a relative path, in which it becomes just PYTHONPATH=..
I realize that won't work in a Windows shell. You'd instead set it using a target specific variable:
train: export PYTHONPATH=.
Related
I started looking into files such as:
/etc/profile
~/.bash_profile
etc.
in order to locate where environment variables were defined. Unfortunately, I couldn't locate the $PATH variable. I am using Bash.
The initial PATH environment variable is inherited from ... whatever launched the shell. For example commands like sudo, sshd, whatever creates your shall after a desktop login.
There also appears to be a PATH that is hardwired into the bash binary for cases where an initial PATH is not inherited. (Look at the output from strings /bin/bash.)
Then various shell initialization scripts get a go at setting or updating PATH. For example, on Ubuntu the PATH variable is updated by /etc/profile.d/apps-bin-path.sh ... which is run by /etc/profile.
You should not worry (or even ask) where PATH is set, since you should not be trusting a random distro to put the right directories in the right sequence.
Instead, you set the PATH you need in your shell's profile. That's it.
As a starting point, POSIX mandates that getconf PATH returns the system's default PATH. If you have a $HOME/bin and there's a /usr/local/bin, then you add them.
Here's what this looks like on my machine:
PATH="$(/usr/bin/getconf PATH)"
PATH="$PATH:/usr/sbin"
PATH="$PATH:/usr/local/bin"
PATH="$PATH:$HOME/bin"
With this setup, it's easy to adapt the sequence. Maybe you don't like the ancient vim in /usr/bin/vi? Compile it yourself and move /usr/local/bin to the front.
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 putting together a makefile in a Windows environment for my team to use. I decided to use MinGW's version of make for Windows. I put that executable with its dependencies into a repository location that should be in everyone's PATH variable. The executable was renamed "make.exe" for simplicity.
Then I realized that I have to account for the case when someone has cygwin's bin folder in their path. Commands like echo, rmdir, and mkdir will call echo.exe, rmdir.exe, and mkdir.exe from cygwin's bin folder. This means that I need to appropriately catch this scenario and use different flags for each command.
I see three cases here:
Cygwin's bin path comes before the path where make.exe is located in the repository. When a team member executes make.exe, they will be executing cygwin's make. Unix-style commands must be used.
Cygwin's bin path comes after the path where make.exe is located in the repository. The correct make.exe will be executed, but I still have to use Unix-style commands.
Cygwin is not installed or not in the PATH. I can use all Windows commands in this case.
I am fine with treating cases 1 and 2 the same. Since MinGW's make and cygwin's make are both based on GNU Make, then I don't see this being much of an issue other than incompatibility issues between versions of GNU Make. Let's just assume that isn't a problem for now.
I have come up with the following check in my makefile.
ifneq (,$(findstring cygdrive,$(PATH))$(findstring cygwin,$(PATH))$(findstring Cygwin,$(PATH)))
#Use Unix style command variables
else
#Use Windows style command variables
endif
Finding "cygdrive" in the path variable means that we are most likely in case 1. Finding "cygwin" or "Cygwin" in the path variable most likely means that we are in case 2. Not finding either string in the path most likely means that we are in case 3.
I am not completely fond of this solution because the cygwin's folder can be renamed or the string "cygwin" or "cygdrive" can be put in the PATH variable without having cygwin installed. One team member is still having issues as he has cygwin's bin path in the PATH variable, but the above does not catch that. I am assuming that he renamed the folder to something else, but I haven't been able to check on that.
So is there a better way to figure out what syntax that I should be using?
Here is another solution that I thought up.
ifeq (a,$(shell echo "a"))
#Use Unix style command variables
else
#Use Windows style command variables
endif
This is based on the fact that 'echo "a"' in Unix will print a (without quotes) but windows will print "a" (with the quotes). If I am using the Unix style echo then I can assume that I am using all Unix commands.
I don't find this solution very elegant though, so I am not marking it as the solution for this question. I think this is better than what I originally had though.
Cygwin make v. MinGW make: Does mingw make support the jobserver, as in can you do make -j5? If not, ${.FEATURES} has jobserver for cygwin make. Maybe load is a good test too.
Cygwin before non-cygwin on path: cygpath.exe is unique to cygwin. You could just look for this in ${PATH}. Unfortunately, Windows users like using spaces in folder names, and there's no way of dealing with this in pure make. $(shell which make) will return /usr/bin/make for cygwin, though a shell invocation on every make run is very smelly.
You don't install a compiler from a repository, is not make a similar case? Just get your users to install cygwin and be done with it.
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.