I just spent some time messing around with my environment variables. I used to be able to type "atom [filename]" into the command prompt and it would open the file in atom (provided I was in the correct directory). Now when I try this, I get the following message:
'atom' is not recognized as an internal or external command,
operable program or batch file.
I've looked at several threads about this and I have added the path:
C:\Users\[username]\AppData\Local\atom\bin
to my Path variables (both user and system). Why is it still not working? It has worked in the past and I'm not sure what has changed.
1/3/2019 Update:
I can open it if I type atom.cmd, but when I removed the .cmd extension and it stopped working. I still am not quite sure why it can't be recognized as a command without this extension as my computer did used to be able to recognize it.
Found the issue:
In my system variable PATHEXT, I did not have the extension cmd, just CMD. These extensions are clearly case sensitive, because adding cmd fixed the problem.
I'm trying to use Cygwin to run some astrophysics code called FAST through a program called IDL. In order to do this, I need to set environment variables for the installation path of IDL and the directory of IDL. When I go to the system variables tab in the system settings, I name the variable as appropriate and set the value to C:\Program Files\Exelis\IDL85, but I get an error saying that
STUDENT#SES-6TTJK72 /cygdrive/c/Users/Administrator/Downloads/FAST_v1.0/FAST_v1.0/example_phot
$ ../fast
../fast C:\Program Files\Exelis\IDL85 .:+C:\Program Files\Exelis\IDL85/lib
../fast: line 6: C:\Program: command not found
Now this seems to be happening because Cygwin can't read the space in Program Files as space is used to delimit the arguments, but I've tried every solution I can think of to get around this. I've tried Program\ Files, I've tried quotes around the whole thing, etc. I was just wondering if there was some way to set the windows environment variables in Cygwin itself so I can just type the path out in the notation that Cygwin uses and it would be able to understand it for sure. Any help on this would be much appreciated!
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
My basic problem is that if I run GCC from the windows command line (cmd.exe in Windows XP) and it does nothing: no .o files are created, no error messages, nothing. It will only throw an error message if I use DOS-style paths, but nothing else. When I run from the Cygwin shell then it will throws error messages as appropriate for the errors in the source and produces the .o files as it needs. Using 'make' from the DOS command line doesn't work either. Has anyone encountered this behavior before?
I've actually made some progress on this. Background:
I have WinAVR installed and its bin directories set in my PATH. WinAVR is GCC and associated development utilities but for the AVR 8-bit microcontroller. It shares many utility names with regular GCC.
In the past I remember Cygwin putting its bin directories in the PATH. It didn't seem to do this this time, so I put 'C:\cygwin\bin' into the PATH and then later 'C:\cygwin\usr\bin' there as well.
The latest release of Cygwin has issues with the way it handles files. Basically, gcc.exe is not an executable, but a type of symlink to the actual executable (which is either gcc-3.exe or gcc-4.exe depending on what you have installed). In the BASH shell these symlinks are easily resolved, in cmd.exe they are not. This means that if you attempt to enter 'gcc' into cmd.exe as a command it will respond 'Access is denied'. The solution for that is to call the actual GCC file name (gcc-4) instead of the symlink.
The solution seems to have come by rearranging my PATH. To edit the PATH environment variable, right click on 'My Computer' and go to properties, then Advanced and then Environment Variables. Under 'System Variables' find 'Path' and double click it to edit. Remove all entries that have C:\cygwin in them and then go to the FRONT of the PATH and enter them there. For me it was C:\cygwin\bin and C:\cygwin\usr\bin. The important part for me was making sure that the Cygwin entries were before the WinAVR entries. I noticed that when I tried to call 'make' in cmd.exe it was calling the WinAVR version instead of the Cygwin version. This lead me to rearrange my path and after some fooling around it became clear that using gcc-4 from the cmd.exe shell was working. It then worked in Code::Blocks as well and I was off.
Alternatively, it might have just fixed itself from something else entirely. Computers have a way of doing that.
Alternatively you can delete file: gcc.exe which is a file link and rename
the actual gcc executable file: gcc-3.exe (or gcc-4.exe depends on your version) to gcc.exe
This is probably batch scripting 101, but I can't find any clear explanation/documentation on why this is happening or if my workaround is actually the solution. So basically any terminology or links to good sources is really appreciated.
So I have a program I want to execute via batch script (along with several other programs). It's the only one where the exe is not in a Program Files folder. I can get it to start like this:
C:\WeirdProgram\WeirdProgramModule\weirdmodule.exe
But I get an error along the lines of:
Run-time Error '3024':
Could not find file
C:\Users\MyUserName\Desktop\ModuleSettings.mdb
So it seems that the program is looking for its settings files from the same location that the batch script starts up. Given that I finally got everything to work by doing the following:
cd C:\WeirdProgram\WeirdProgramModule\
weirdmodule.exe
That works fine, and it's not the end of the world to have to go this route (just one extra line), but I've convinced myself that I'm doing something wrong based on lack of basic understanding.
Anybody know or can point me to why it works this way?
Oh, and doing the following:
start "C:\WeirdProgram\WeirdProgramModule\weirdmodule.exe"
doesn't do anything at all.
Thanks,
you are doing it perfectly :-)
the executable is probably looking for this file in the "current working directory", which is being set, when you "cd" to it before.
you can set your working directory manually by creating a shortcut to your batch file; right click; properties.
edit:
you can also set your current working directory using the start command:
start "Title" /D "C:\WeirdProgram\WeirdProgramModule\" "weirdmodule.exe"
edit:
If you like to pass params, just add them to the executable filename as you would in a regular shortcut:
start "Title" /D "C:\WeirdProgram\WeirdProgramModule\" "weirdmodule.exe" "param1 param2"
or
start "Title" /D "C:\WeirdProgram\WeirdProgramModule\" "weirdmodule.exe param1 param2"
For reference, the syntax is described here: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds.mspx?mfr=true.
What's happening is that weirdmodule.exe is looking in the "current directory" for the .mdb file. You might be able to tell it where to find the .mdb file through a command line parameter or some other configuration method (registry or .ini file maybe). How you'd specify the location is entirely up to the weirdmodule.exe program, though.
Other than that, your current workaround is probably what you're stuck with.
As far as your problem with using start.exe... the start.exe program has the very, very odd behavior (bizarre behavior in my opinion) of treating the first parameter as the 'title' to put in the window if (and only if) the first parameter is in quotes. So you have a couple of options:
Don't use quotes to specify the program. This works for you because you don't need quotes (there aren't any spaces or other special characters in the path that would require quoting it):
start C:\WeirdProgram\WeirdProgramModule\weirdmodule.exe
Give an empty (or some other string) title as the first parameter. This is something you'd have to do if your path required quotes:
start "" "C:\WeirdProgram\WeirdProgramModule\weirdmodule.exe"