I am using a makefile in windows to push some files on a Unix server (here a text file "blob.txt" in the same folder of my makefile).
My makefile script is:
setup:
pscp blob.txt username#hostname:/folder/
I start a command prompt, go in the folder where blob.txt and the makefile are present and type:
make setup
Which results in:
pscp blob.txt username#hostname:/folder/
process_begin: CreateProcess(NULL, pscp blob.txt username#hostname:/folder/, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [setup] Error 2
In a #fail ... whereas if I enter directly the command in the command prompt:
pscp blob.txt username#hostname:/folder/
It works ... I really wonder why.
The error
process_begin: CreateProcess(NULL, pscp blob.txt username#hostname:/folder/, ...) failed.
make (e=2): The system cannot find the file specified.
is almost certainly complaining that Windows cannot find pscp.
This is almost certainly because the value of %PATH% (or whatever) is different when make spawns a shell/console then when you have it open manually.
Compare the values to confirm that. Then either use the full path to pscp in the makefile recipe or ensure that the value of PATH is set correctly for make's usage.
I didn't want to remove GIT's bin folder from the PATH variable (I am using a Windows machine), as I use it quite often. So I looked for a workaround, and here it is:
Add the <git-installation-directory>/usr/bin directory to your PATH variable too. This basically adds the rest of the linux-like commands that come with the "GIT bash" to your environment. After applying this, my makefiles ran normally again. :)
If you are curious about what shell is being invoked by make, just add $(info $(SHELL)) at the beginning of your makefile. The path/name of the shell being invoked is printed to the console as soon as you run make.
I know this is an old question that has been answered, but thought I'd and my experiences for anyone still running into this. I was getting the same cryptic error Colonel Beauvel (though with the windows MOVE command, not pscp):
process_begin: CreateProcess(NULL, move /y foo\bar.c .\baz.c, ...) failed.
make (e=2): The system cannot find the file specified.
Our CI was running the same Makefile and working perfectly. Turns out CI was using mingw32-make and I was using GNU make. Uninstalling GNU make (which got installed as part of an unrelated bulk package) and aliasing mingw32-make to 'make' works perfectly.
#user3869623's solution works for me. I'd like to share some details of mine to complete the picture.
My makefile contains below target:
clean:
#echo '$(OS)'
ifeq ($(OS),Windows_NT)
del /s *.o *.d *.elf *.map *.log
endif
When I run make clean, I see this error:
Since it says something went wrong with echo, so I change my makefile target to below:
clean:
ifeq ($(OS),Windows_NT)
del /s *.o *.d *.elf *.map *.log
endif
This time, make clean gives me this error:
I am surprised to see bash here since I am working in Windows command line.
Then I checked my %PATH%, I see this entry:
C:\DevTools\Git\bin
There's a bash.exe and sh.exe in that path. So I removed this entry, and it works fine now.
BUT I STILL DON'T KNOW WHY BASH GET INTO THIS???
ADD 1
As to why the C:\DevTools\Git\bin shows up in my %PATH%, because I am using Sublime and it always asks me for the Git binaries:
In my case, I had git\bin in my %PATH% which contains bash.exe and sh.exe.
Removing %GIT_HOME%\bin from the PATH worked for me.
To build on user3869623's response.
In my case i had git\bin in my %PATH% which contains bash.exe and sh.exe.. Removing %GIT_HOME%\bin from the PATH worked for me
While this recommendation may allow make to run, it will likely cause issues for git, especially if the makefile is installing software from a git repository.
A better solution is to simply change %GIT_HOME%\bin to %GIT_HOME%\cmd
For those who tried removing the git bin folder from PATH and it didn't work for them, search your PATH variables for any paths containing bash.exe.
In my case I found a variable linking to cygwin bin folder C:\cygwin64\bin, removed it and it worked.
I had the same issue, and this thread really helped me solve it. In my case, it was a conflict between make and the sh.exe that was visible through my path, due to both git and mingw64. To fix my issue, without breaking Git, I added these lines to the top of my batch file that calls make:
set path=%path:git\bin=;%
set path=%path:mingw64\bin=;%
set path=%path:usr\bin=;%
This hides the extra sh.exe instances from make for that instance only.
I ran into this problem recently and this question was one of the top hits for my searches.
None of the other answers here helped me. The fix, for me, was to put the binary name in quotes:
setup:
"pscp" blob.txt username#hostname:/folder/
-"pscp" blob.txt username#hostname:/folder/ # Failure is OK, `-` in front
I'm on windows.
By explicitly setting my compiler to gcc (instead of cl?) it solved my problem.
CC = gcc
I hope some people more knowledgeable than me could explain why changing the compiler would impact the makefile parsing.
I'm following this tutorial: https://www.youtube.com/watch?v=mYnfix8ruAo
for compiling PDCurses and linking it to a CodeBlocks project, but I keep getting an error ('mingw32-make' is not recognized as an internal or external command, operable program or batch file.)
The thing is, I definitely have mingw installed properly, and have a path pointing to it in the system environment variables.
http://puu.sh/id6nC/3ab670cbdc.png
In the terminal, I tried the command twice without specifying a target file to make sure it's recognized, and it is. It's not until after I get to the point that I want to build the library that it stops recognizing it as a command for some reason. I'd really appreciate any help.
This isn't a PDCurses issue, it's a PATH issue. The PATH is an environment variable that the command-line shell uses to locate the executables you type as commands, if they aren't in the current directory, or shell built-ins. It's a list of directories, separated by semi-colons. Each directory is checked in turn, until a match is found.
Specifcally, your problem is this line:
path=c:\CodeBlocks\mingw\bin
Apparently, mingw32-make is not in that location. But, since it was found without that line, you clearly don't need the line -- at least not for that. So, just take it out.
Now, if it later turns out that you do need to add \CodeBlocks\mingw\bin to your PATH for some other reason, then the way to do it is like this:
path=%PATH%;c:\CodeBlocks\mingw\bin
This appends your new path to the existing PATH, instead of wiping out the existing PATH and replacing it with that directory alone.
I am trying to run a bash file from install4j6. install4j does indeed try to run the bash file but it just returns an error at the end of the installation. The error is very generic and has no code reference or anything that will help me determine a solution - just a message that says "Error while executing file."
The only thing I can provide is how I have it setup in install4j6 since I am pretty sure that's my issue.
The bash file is defined in the root of my installation directory distribution tree and is named set_permissions.sh. For the sake of eliminating permissions being a cause, the file permission mode is set to 777 (both in install4j and on the file system).
I believe the issue is related to what I have set as my "working directory". I currently have it set to just ".". Is there a way to debug this further? Maybe get an actual error as to why it's not executing?
Ok, first a few things to check:
make sure that you're running the batch file after the install files step (you mention it being at the root of your install)
best to have the wait for termination checked and a variable for the return code.
redirect stderr to the log file (just in case)
As for working directory, . should work, but you can change it to ${installer:sys.installationDir} to make sure that it references the installation directory chosen by the user. You can also set the executable in the form of ${installer:sys.installationDir}\set_permissions.sh
Also, try and run just your shell script to make sure that it works :)
I installed Strawberry Perl to run the rouge program in Windows. But when I want to run my program, I receive an error message that you can see on the image:
The system can't find the path specified.
My code is attempting to run "ROUGE-1.5.5.pl" but i think the system can't find this file. So I think maybe I don't initialize the path correctly?
I change my code to :
#!/usr/bin/perl
use Cwd;
$curdir=getcwd;
$ROUGE="..\ROUGE-1.5.5.pl";
chdir("sample-test");
$cmd="$ROUGE -e ..\data -c 95 -2 -1 -U -r 1000 -n 4 -w 1.2 -a DUC2002-ROUGE.in.26.spl.xml > ..\sample-output\output.out";
print $cmd,"\n";
system($cmd);
chdir($curdir);
and i receive this error:
Missing braces on \o{} at C:\runROUGE-test.pl line 7, near "$ROUGE" Execution of C:\runROUGE-test.pl aborted due to compilation errors.
As per the screen shot, you are attempting to run \ROUGE-1.5.5.pl where you probably want it without the spurious backslash (or with ..\ROUGE-1.5.5.pl if the parent directory is not on your PATH).
Similarly, you probably want the output in sample-output\output.out, or even just output.out, not \sample-output\output.out unless you specifically have a folder C:\sample-output for this purpose.
The backslash is significant; it is the absolute path to the root (of the current drive, on Windows). ..\ is the relative path to the parent folder.
Why are you writing a Perl script to run a Perl script, though? Either a simple batch file, or copy/pasting the command directly at the DOS prompt would seem like a less roundabout solution.
The problem is that when you are outputting the contents of the program to the file output.out in folder sample-output, the sample-output folder does not exist.
Command Prompt will not create the folders for you, only the files. Try creating a directory first called "sample-output" (In your drive root) such that the path resolves to something like C:\sample-output and run it again.
If the same problem results, try using an absolute path such as C:\sample-output\output.out instead.
I'm trying to instal Extension:Scribuntu, but when I try to run simple command, like #invoke I get the error:
Lua error: Internal error: The interpreter exited with status 127.
This is what I found in error logfile:
sh: /var/lib/php-exec//sh /alt/home/webmaster.plast/html/Wiki/extensions/Scribunto/engines/LuaStandalone/lua_ulimit.sh 7 8 51200 \\/alt/home/webmaster.plast/html/Wiki/extensions/Scribunto/engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic/lua\: No such file or directory
So my question is: can You tell me if the paths are correct? I've checked the files and they are all in place. Paths also are absolute so I have no idea where the problem is. Are those "\" before path correct?
I have never used shell before so i don't even know the correct syntax. Thank You for simple explanation.
There should be no "\" in the path, but it's possible that this is an artifact of the error reporting/logging machanism. Do check though.
Another thing to check is that the user executing the code actually has the permissions needed to read and run the lua executable (and the directory where it resides, and all parent directories). For apache under Debian or Ubuntu, that user would typically be www-data. It should be fine to make the lua executable readable and runnable for all users.