I was trying to use the pip package
virtualenvwrapper
in Windows through gitbash. The standard virtualenvwrapper-win doesn't work in gitbash and it's useful to not have to switch between consoles so I generally install both.
Normally you simply need to open your .bashrc file in your home directory and type something akin to the following:
export WORKON_HOME=$HOME/Envs/
source Path/To/Python/Scripts/virtualenvwrapper.sh
In this case, however, this produced an error complaining that it reached EOL (end of line) while scanning the string literal. It showed the offending line and it was trying to combine the gitbash $HOME variable (with forward slashes) with the windows environment variable (with the backslashes).
How can I fix it so that it's not combining the environment variables?
The first solution is to manually force the script to find the right path by opening virtualenvwrapper.sh and editing line 126:
"$VIRTUALENVWRAPPER_PYTHON" -c "import os,sys; sys.stdout.write('/path/to/your/envs/folder')"
The underlying cause, however, occurs if you try to set an environment variable in windows for WORKON_HOME. If you simply want to share the Envs folder in your home directory, delete the WORKON_HOME environment variable you created in windows and the issue should go away.
If you want it in a completely different place, then use the absolute path (no environment variables such as %USERPROFILE%) in the windows environment variable and it should work.
I have Windows 7 and tried to use the 'make' command but 'make' is not recognized as an internal or external command.
I did Start -> cmd -> run -> make, which outputs:
'make' is not recognized as an internal or external command,operable program or batch file.
Then I typed 'mingw32-make' instead of 'make' (Start -> cmd -> run -> mingw32-make) and I get the same output:
'mingw32-make' is not recognized as an internal or external command,operable program or batch file.
What shall I do next in order to fix this problem?
In Windows10, I solved this issue by adding C:\MinGW\bin to Path and then called it using MinGW32-make not make.
Your problem is most likely that the shell does not know where to find your make program. If you want to use it from "anywhere", then you must do this, or else you will need to add the full path each time you want to call it, which is quite cumbersome. For instance:
"c:\program files\gnuwin32\bin\make.exe" option1=thisvalue option2=thatvalue
This is to be taken as an example, it used to look like something like this on XP, I can't say on W7. But gnuwin32 used to provide useful "linux-world" packages for Windows. Check details on your provider for make.
So to avoid entering the path, you can add the path to your PATH environment variable. You will find this easily.
To make sure it is registered by the OS, open a console (run cmd.exe) and entering $PATH should give you a list of default pathes. Check that the location of your make program is there.
This is an old question, but none of the answers here provide enough context for a beginner to choose which one to pick.
What is make?
make is a traditional Unix utility which reads a Makefile to decide what programs to run to reach a particular goal. Typically, that goal is to build a piece of software from a set of source files and libraries; but make is general enough to be used for various other tasks, too, like assembling a PDF from a collection of TeX source files, or retrieving the newest versions of each of a list of web pages.
Besides encapsulating the steps to reach an individual target, make reduces processing time by avoiding to re-execute steps which are already complete. It does this by comparing time stamps between dependencies; if A depends on B but A already exists and is newer than B, there is no need to make A. Of course, in order for this to work properly, the Makefile needs to document all such dependencies.
A: B
commands to produce A from B
Notice that the indentation needs to consist of a literal tab character. This is a common beginner mistake.
Common Versions of make
The original make was rather pedestrian. Its lineage continues to this day into BSD make, from which nmake is derived. Roughly speaking, this version provides the make functionality defined by POSIX, with a few minor enhancements and variations.
GNU make, by contrast, significantly extends the formalism, to the point where a GNU Makefile is unlikely to work with other versions (or occasionally even older versions of GNU make). There is a convention to call such files GNUmakefile instead of Makefile, but this convention is widely ignored, especially on platforms like Linux where GNU make is the de facto standard make.
Telltale signs that a Makefile uses GNU make conventions are the use of := instead of = for variable assignments (though this is not exclusively a GNU feature) and a plethora of functions like $(shell ...), $(foreach ...), $(patsubst ...) etc.
So Which Do I Need?
Well, it really depends on what you are hoping to accomplish.
If the software you are hoping to build has a vcproj file or similar, you probably want to use that instead, and not try to use make at all.
In the general case, MinGW make is a Windows port of GNU make for Windows, It should generally cope with any Makefile you throw at it.
If you know the software was written to use nmake and you already have it installed, or it is easy for you to obtain, maybe go with that.
You should understand that if the software was not written for, or explicitly ported to, Windows, it is unlikely to compile without significant modifications. In this scenario, getting make to run is the least of your problems, and you will need a good understanding of the differences between the original platform and Windows to have a chance of pulling it off yourself.
In some more detail, if the Makefile contains Unix commands like grep or curl or yacc then your system needs to have those commands installed, too. But quite apart from that, C or C++ (or more generally, source code in any language) which was written for a different platform might simply not work - at all, or as expected (which is often worse) - on Windows.
First make sure you have MinGW installed.
From MinGW installation manager check if you have the mingw32-make package installed.
Check if you have added the MinGW bin folder to your PATH. type PATH in your command line and look for the folder. Or on windows 10 go to Control Panel\System and Security\System --> Advanced system settings --> Environment Variables --> System Variables find Path variable, select, Edit and check if it is there. If not just add it!
As explained here, create a new file in any of your PATH folders. For example create mingwstartup.bat in the MinGW bin folder. write the line doskey make=mingw32-make.exe inside, save and close it.
open Registry Editor by running regedit. As explained here in HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER go to \Software\Microsoft\Command Processor right click on the right panel New --> Expandable String Value and name it AutoRun. double click and enter the path to your .bat file as the Value data (e.g. "C:\MinGW\bin\mingwstartup.bat") the result should look like this:
now every time you open a new terminal make command will run the mingw32-make.exe. I hope it helps.
P.S. If you don't want to see the commands of the .bat file to be printed out to the terminal put #echo off at the top of the batch file.
If you already have MinGW installed in Windows 7, just simply do the following:
Make another copy of C:\MinGW\bin\mingw32-make.exe file in the same folder.
Rename the file name from mingw32-make.exe to make.exe.
Run make command again.
Tested working in my laptop for above steps.
For window-10 resolved error- make' is not recognized as an internal or external command.
Download MinGW - Minimalist GNU for Windows from here https://sourceforge.net/projects/mingw/
install it
While installation mark all basic setup packages like shown in image
Apply changes
After completion of installation
copy C:\MinGW\bin
paste in system variable
Open MyComputer properties and follow as shown in image
You may also need to install this
https://sourceforge.net/projects/gnuwin32/
As other answers already suggested, you must have MinGW installed. The additional part is to add the following two folders to the PATH environment variable.
C:\MinGW\bin
C:\MinGW\msys\1.0\bin
Obviously, adjust the path based on where you installed MinGW. Also, dont forget to open a new command line terminal.
'make' is a command for UNIX/Linux. Instead of it, use 'nmake' command in MS Windows. Or you'd better use an emulator like CYGWIN.
Search for make.exe using the search feature, when found, note down the absolute path to the file. You can do that by right-clicking on the filename in the search result and then properties, or open location folder (not sure of the exact wording, I'm not using an English locale).
When you open the command line console (cmd) instead of typing make, type the whole path and name, e.g. C:\Windows\System32\java (this is for java...).
Alternatively, if you don't want to provide the full path each time, then you have to possibilities:
make C:\Windows\System32\ the current working directory, using cd at cmd level.
add C:\Windows\System32\ to you PATH environment variable.
Refs:
use full path: http://technet.microsoft.com/en-us/magazine/ff678296.aspx
cd: http://technet.microsoft.com/en-us/library/cc731237.aspx
PATH: http://technet.microsoft.com/en-us/library/bb490963.aspx
I am using windows 8. I had the same problem. I added the path "C:\MinGW\bin" to system environment variable named 'path' then it worked. May be, you can try the same. Hope it'll help!
try download & run my bat code
======run 'cmd' as admin 2 use 'setx'=====
setx scoop "C:\Users%username%\scoop" /M
echo %scoop%
setx scoopApps "%scoop%\apps" /M
echo %scoopApps%
scoop install make
=======Phase 3: Create the makePath environment variable===
setx makePath "%scoopApps%/make" /M
echo %makePath%
setx makeBin "%makePath%/Bin" /M
echo %makeBin%
setx Path "%Path%;%makeBin%" /M
echo %Path%
use mingw32-make instead of cmake in windows
Does anyone know where to put the cdlatex.el script written by C. Dominik to allow swift LaTeX math insertion within an *.org file? CDLatex is a minor mode that can work with Org-mode, at least that's what I gather.
I've followed the instructions given [in this link] but when I type M-x org-cdlatex-mode RET I get "Cannot open load file: no such file or directory, cdlatex" in the Emacs' echo buffer. What does it mean? I've also tried looking for a package named "cdlatex" in the list of packages (M-x list-packages) but there wasn't any. How do I get this minor mode activated in Org?
I'm running Windows 7, Emacs 24.1, Org-mode 8.2.10, AUCTEX 11.88, TexLive 2015. At least another user has this same problem, please check this address.
My emacs working path file is C:\home\.emacs.d\. Do I put the script in C:\home\.emacs.d\elpa\? Inside the ~\.emacs.d\elpa\ I also have yasnippets and auctex directories, among others. Here's a snapshot:
Put the cdlatex.el script in one of the Load paths. To find all the load paths type C-h v RET load-path RET, then pick one and place the script in there. Restart emacs (or the machine if you prefer) and try out the CDLaTeX mode in one of the *.org files by enabling it either through menu or keyboard command:M-x org-cdlatex-mode RET.
Unfortunately for me there's some configuration problem because every time I type backquote or backtick (`), Org doesn't seem to recognize it when in CDLaTeX mode. It says: "Wrong type argument: characterp, 134217782"
This works (Notepad++):
C:\Anywhere> start notepad++ hello.txt
And this works (SoX for removing silence in sounds):
C:\Anywhere> sox in.wav out1.wav silence 1 0.1 1%
Yet, my PATH variable includes neither (would send on request).
How can I do this with my program?
To run from everywhere.
Also, why doesn't Notepad++ work without the start command?
(I did this workaround by putting the .exe in C:\ and then simply calling C:\Anywhere> /myprogram but I'm still curious about the above.)
To get the indicated scenario where
you can start applications from anywhere using the start command (or the windows Run dialog) without including its parent folder in path variable,
but you can not start the application without the start command from any directory whithout including the full path to reach it (it is not in the path) or being located in the adecuated directory
the applications are included in the registry under the key
HKEY_CLASSES_ROOT\Applications
note: It is a "merged" view showing the combined contents of
HKEY_LOCAL_MACHINE\Software\Classes\Applications
HKEY_CURRENT_USER\Software\Classes\Applications
If you are not administrator to change the local machine configuration, you can always modify your user registry information to include the applications you need.
edited There is a second place in registry that will allow to include an application in the registry to be executed using start command, Run dialog or from anything that uses the ShellExecute or ShellExecuteEx API calls.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\
I have installed ActivePerl on my Windows OS. I have followed below URL
procedure to install
ActivePerl Installation
After having done that, I have tried to run "perl -v " on the command line. But it reports the following error.
The system cannot execute the
specified program
What do I need to do to solve these issues?
I was facing a similar issue... but the thing was that I could execute the file by right clicking the file and opening it with perl command line interpreter.... but still the perl-v command would give the error... all I had to do was execute this command
set PATH=C:\Perl\bin;%PATH%
This solved the issue...
You need to make sure the directory where the Perl executable lives (it might be C:\perl\bin, but basically wherever you told ActiveState Perl to be installed) is in your PATH environmental variable (you can find the variable value by typing set PATH command on command line prompt in Windows).
If you're not sure where you installed Perl to (and can't find it in the default C:\perl\bin), you can find the directory by going to Start menu, finding ActiveState Perl folder, and right-clicking on "Perl Package Manager" icon, then pick "Properties" from the right-click menu. Properties window (in the "Shortcut" tab) will have a "Target" line showing the directory.
I was getting a similar error after installing ActiveState Perl on Windows 8 x64 bit edition and trying to invoke 'perl' at the command line.
'perl' is not recognized as an internal or external command, operable
program or batch file.
I remember selecting the option during installation to add the Perl directory to the system PATH environment, and after checking the system properties, it was indeed showing in the system PATH.
I tried installing 'Microsoft Visual C++ 2008 x86 and x64 redistributable setup' files as suggested by a few places but it still did not resolve the issue, until I tried some of the suggestions in this thread.
At the command prompt I entered:
set PATH
And surprisingly it did not list the Perl directories as being included in the PATH variables.
So to remedy that I entered this into the command prompt and hit enter:
set PATH=C:\Perl64\bin;C:\Perl64\site\bin;%PATH%
(The directory paths are for the 64 bit edition of Perl, adjust according to your installation) the %PATH% portion is important and ensures your existing settings are kept and not wiped out and overwritten when you set the PATH.
That fixed it and entering 'perl -v' into command prompt successfully replies your Perl version. If you had a PowerShell window open before setting the PATH variable, you will need to close it and re-open another instance of PowerShell.
I believe the original underlying issue was something to do with different PATH variables for 32-bit and 64-bit environments and possibly some internal Windows redirection that takes place automatically.
This doesn't sound like a problem with PATH - I would expect it to give the message 'perl' is not recognized as an internal or external command, operable program or batch file.
I have not seen this error message, but http://nirlevy.blogspot.com/2008/03/system-cannot-execute-specified-program.html makes some suggestion for related programs.
Or maybe ask on an Active State forum.
I had the same error. I was able to solve it by changing the order of the Perl64 entries in the PATH variable in the Environment Variables. I moved the C:\Perl64\bin to be before C:\Perl64\site\bin and it worked.
I had a similar error which was solved by adding the .pl extension to the script name, which I had forgotten to do.
I could not get it to work otherwise even with my Perl's location (C:\Apps\Perl\bin) verified as in %PATH%.
The problem lies in the installation directory.
The Perl PATH variable will be set to C:\Program Files\perl (depends on 32 or 64 bit of course), BUT, the default installation directory is C:\perl. This is kind of sneaky actually as you would assume the installer would be more intelligent about this, but it sets the environment variable to that directory no matter WHERE you install the damned thing.