I have recently moved from Window 7 to Windows 10 and I cannot get my makefiles to work anymore.
I have been using the GNU Make for Windows
The first thing that I noticed was that it had started treating Windows folder dividers (backslash characters '\') as line continuation characters, so I modified the 'clean' section as shown below to use forward slash '/' characters instead:
clean:
del $(ObjDir)/*.o
When I call make -ftest.mak clean I get the following error which suggests it is now trying to run in a MinGw/Cygwin environment:
c:\Test\Source>make -ftest.mak clean
del obj/*.o
/usr/bin/sh: del: command not found
make: *** [clean] Error 127
I do have MinGw folder on my PC (which I have renamed to stop make looking for it) and I can't see any 'MingGw' related environment variables in my Cmd.exe environment or PATH
How can I get make working so it doesn't try executing sh under Windows?
Is there some configuration parameter somewhere that makes it call sh instead of cmd.exe?
Update: Just tried running make -d which logs debug output. It looks as though it is using my Git folder as some sort of root folder:
Must remake target `clean'.
del obj/*.o
CreateProcess(NULL,C:/Program Files/Git/usr/bin/sh.exe -c "del obj/*.o",...)
Putting child 0x006e7fc0 (clean) PID 7234712 on the chain.
The cleanest way is to specify SHELL on command line.
make -ftest.mak clean SHELL=cmd
will do the job. ndk-build will do that for you, see your ndk-build.cmd. Don't try to run ndk-build bash script on Windows. The scripts in NDK may go amoc when you run them on Windows in bash.
Nasty conclusion to this problem.
make looks through the PATH environment variable for anything containing usr/bin. It just so happens that since I also installed Git on my Windows 10 PC, Git added the following folder to PATH:
C:\Program Files\Git\usr\bin
Adding any path with the substring "usr\bin" will cause make to try running sh instead of cmd.exe on Windows.
My solution: Remove the C:\Program Files\Git\usr\bin from my PATH.
Update: I changed the name from usr\bin to user\bin but make still finds sh.exe within that folder. In the end I renamed sh.exe to _sh.exe within the Git\usr\bin folder.
Related
I'm having an issue with WSL2:
$ where b4a
/usr/local/bin/b4a
$ b4a new
/usr/local/bin/b4a: 1: Not: not found
Even though where finds commands, I can't run them. And it's not a PATH issue either:
echo $PATH
/usr/local/sbin:/usr/local/bin:[...]
And b4a isn't the only command with this problem. What could be the cause? My distribution is Debian 10 and host is Windows 10.
Not necessarily a full answer, but hopefully the troubleshooting methods you need to arrive at a solution ...
Note that it doesn't say that the command itself isn't found. For instance, if you run:
# lllllllllll
lllllllllll: command not found
That's truly a command not found. This is different. While I don't (yet) know the exact cause, this seems closer to the issues we might see with improperly quoted paths with spaces in a shell script.
You mention that other commands have this problem -- Is there something in common with the commands that don't work properly? Is it possible that they are all shell scripts?
Try several things to debug:
Start WSL without your startup profile. It's very likely that something (or you) added a line that is causing problems. From PowerShell or CMD:
wsl ~ -e bash --noprofile --norc
b4a
If that works, then there's a problem in one of your startup files that you'll need to debug. Look for anything modifying environment variables without proper quoting, especially the PATH. WSL automatically appends the Windows path to your Linux path to make it easy to run Windows commands, but the fact that almost every Windows path has spaces in it can cause problems for unsuspecting scripters that don't take this corner case into account.
Having a space in a path is fully allowed in Linux, but some scripts just don't handle it properly.
If the command that is failing is a shell script, trying starting it with:
bash -x /usr/local/bin/b4a
Or even start WSL with wsl ~ -e bash -x to see all trace output from the shell.
In this case, you'll be looking for some problem in the script right around where it actually fails.
If all else fails, you can disable WSL's PATH modification via its config file:
sudo -e /etc/wsl.conf
Add the following:
[interop]
appendWindowsPath = false
Then exit Debian, run wsl --shutdown and restart Debian. Try the b4a command again.
If this works, then the problem is almost certainly due to some problem in the PATH quoting in these commands. I don't recommend it as a permanent solution since you will have to type out the full path of Windows applications each time you want to run them.
I'm trying to init my first NestJS project but met this fail:
-----------------------------------------
$ nest new testproj
⚡ We will scaffold your app in a few seconds..
'node' is not recognized as an internal or external command,
operable program or batch file.
Failed to execute command: node #nestjs/schematics:application --name=testproj --directory=undefined --no-dry-run --no-skip-git --no-strict --package-manager=undefined --language="ts" --collection="#nestjs/schematics"
------------------------------------------
Tryed to reinstall NodeJS, but no luck.
$ node -v
v16.13.1
$ nest -v
8.1.6
$ npm -v
8.3.0
Any help will be appreciated.
tl;dr:
If your PATH somewhere has a file in it and not a folder (can also be in the middle of a path, with some \other\stuff appended like C:\stuff\somefile.txt\stuff), then this can happen due to an error when Git bash is translating PATH before calling cmd.exe, resulting in part of the PATH not being forwarded and making binaries in that part "not found".
Details:
After some investigation via chat, it turned out that the root cause was a bad GRADLE_HOME environment variable.
Yes, Gradle has nothing to do with node.js or nest, but bear with me, this is one of those moments where a TV episode starts with a totally crazy scene and you wonder what the heck happened that led to this, and then you get "6 hours earlier..." 😁
So, Git bash obviously succeeded in finding node, because it ran the nest CLI (which is a node script). But then, somehow, cmd (which is called by node when executing shell commands) did not find node. This normally should not happen.
Tracing the events with Process Monitor revealed that bash (sh.exe) passed a truncated PATH variable to node.exe. It just ended abruptly somewhere in the middle, and C:\Program Files\nodejs (which was towards the end of it) was not passed along.
The reason for this turned out to be an entry in the PATH that looked like this: C:\foobar\file.zip\bin. The transition into bash worked, as the full path (including this bad entry as /c/foobar/file.zip/bin) could be seen in bash's $PATH, and /c/Program Files/nodejs was there too.
But the transition from bash to node.exe failed. In the process of converting the Linux-style paths to Windows-style paths before passing the variable on to node.exe, bash silently failed in the middle of the string and stopped processing it - as soon as this /c/foobar/file.zip/bin entry was encountered. C:\foobar\file.zip did exist, and it turns out Git bash behaves like this when it unexpectedly encounters a "not a directory" error from the OS when querying the path segment ("file not found" is fine) - as a result of attempting to access a "subdirectory" of a file. Removing this entry from the PATH made everything work normally.
The source of this entry was actually %GRADLE_PATH%\bin in the Windows PATH, and the reason this caused the problem was that GRADLE_PATH itself was incorrectly set to a file (C:\foobar\file.zip) instead of a directory.
There are three ways to resolve this:
Remove %GRADLE_PATH%\bin from the PATH.
Fix GRADLE_PATH to point to a directory.
Delete or rename the C:\foobar\file.zip file.
I'm trying to activate android studio directly from terminal (./studio.sh)
the installation dir is /usr/local/android-studio
and inside there's a bin folder with the script studio.sh
for that I've vi'd ~/.bashrc to include the following line:
export PATH=$PATH:/usr/local/android-studio/bin
When I do echo $PATH i do see the path above appended to the rest of the path
(/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/android-studio/bin)
Yet when I run ./studio.sh it prompts me with No such file or directory
Needless to say, if i cd /usr/local/android-studio/bin and then ./studio.sh it works fine
running debian (jessie 'edition')
I simply needed to do studio.sh without the ./
Thanks for ZanCoul for providing the answer.
I have a .iss file created in Inno Script Studio. It has a pre-compilation step which is a feature specific to Inno Script Studio. I can run my .iss file from a Command Prompt window (which is running cmd.exe, right?). The command looks like,
"\Program Files (x86)\Inno Script Studio\isstudio.exe" -compile myscript.iss
If instead, I run /c/system/windows32/cmd from a Git bash window and then try the same command I get an error popup with 'I/O Error 6'. Why? Through experimentation the problem seems to be with the myscript.iss argument: if I leave off that argument the isstudio simply complains that the argument is missing.
I have tried various escaping and quoting changes to the command but nothing fixes it. I tried running cmd in a fresh environment with env -i. I have tried providing the full path to the file using a DOS style path with C: and backslashes.
And I tried creating a .bat file with the above command in it: same error.
Can't get Eclipse to build my NDK/JNI project. Eclipse, or ndk-build from a command prompt, both give following output:
/cygdrive/c/android-ndk-r8b/build/core/setup-app.mk:75: recipe for target `clean-installed-binaries' failed
make: *** [clean-installed-binaries] Error 6
What is "Error 6"? I can't find any doc on that anywhere. Helpfully, it doesn't say what the problem is, just giving the cryptic error code.
I found setup-app.mk and tried inserting something to echo the command it was executing, which was simply removing some files. I copied and pasted it to the command prompt and it worked fine on its own:
rm -f ./libs/armeabi/lib*.so ./libs/armeabi-v7a/lib*.so ./libs/mips/lib*.so ./libs/x86/lib*.so
Also tried inserting a "whoami" and it matched a whoami directly from the command prompt, so it's not acting as a different user with different permissions or something.
Been stuck on this for days. Can anyone help?
Rob.
PS. I'm finding Eclipse/NDK/JNI almost impossible to work with. It only seems to work for a week or two before falling in a heap again, seemingly with no change from me. This one is now unusable until I fix this error. I also have it installed on another machine, which is now also completely broken for completely different reasons. How does anyone work in this environment?
It's no miracle the actual command works: the error message comes from the make itself, which failed to generate the appropriate command!
Now what could have happened: most likely, you have some paths with spaces. Make sure that neigher eclipse, cygwin, project, workspace, nor ndk have spaces in their root paths.
Maybe, there is some problem with PATH. I refer to the environment variable in three environments: windows native, cygwin, and eclipse. Could it be that make you actually run is different from what you expect?
Note that you do not need cygwin to build with NDK 7 and higher, simply use ndk-build.cmd.