I have npm and node installed (tried NVM for Windows and direct installations).
When running 'npm -v' or 'node -v' in Git Bash everythings works fine. But when I try to run 'npm run dev' (or any other command) the output says that 'node command is not recognized'.
In other shells (CMD/Powershell) everything works fine.
I've checked Path variable in Windows, Path variable in Git Bash, everything seems to be correct.
Error screenshot
Path variable screenshot
Path variables cmd/procmon
Any help appreciated.
p.s. While I was trying to find an answer I saw the same question from #jameseg , maybe if he sees this one he could help.
Your PATH environment variable is quite a mess. It has duplicate entries, also has an entry C:\Program Files\nodejs\node.exe which is not valid because it should be a folder, not a file, and it has . in the middle which doesn't make much sense either.
But the main problem is that it has a stray doublequote, after C:\Program Files\Java\jdk-13.0.1\bin:
With this, effectively all the paths after it are ignored, because they are treated as part of one big quoted string (which is implicitly terminated by the end of the variable data).
To illustrate what I mean, consider this example:
This correct PATH variable...
C:\a;C:\b;"C:\c 123";C:\d;C:\e
...is interpreted as:
C:\a
C:\b
C:\c 123
C:\d
C:\e
But, this bad PATH variable where I deleted one of the quotes...
C:\a;C:\b;C:\c 123";C:\d;C:\e
...is interpreted like this:
C:\a
C:\b
C:\c 123";C:\d;C:\e
This may at first make only half sense, but it's because of the quirky way Windows parses this variable: When encountering a doublequote, it's removed from the result but toggles a flag that says whether we are now inside a quoted string. And when the flag is set, semicolons are ignored. So even if the stray quote is at the end of a path (or in the middle of it), it will have the effect of essentially quoting the rest of the variable data until the next doublequote or the end of the data.
Confusingly, you may still have where node report that it found node, because the where.exe tool does its own parsing, in a slightly different way (ignoring quotes), so you cannot rely on its output! (For example, try set PATH=c:\win""dows. where explorer will say it can't be found, yet explorer will work to open Explorer. You get the opposite with something like set PATH=x"y;c:\windows - where explorer will list c:\windows\explorer.exe, yet explorer will not work.) The reason why it works in Git Bash is probably the same: when the environment variables are translated to UNIX paths, they are parsed slightly differently than Windows would do it itself, inadvertently correcting the problematic entry in the process.
So, the solution is to remove this doublequote from your path variable.
Related
Lately, I was trying to install NodeJs on my desktop PC and I ran into this weird problem. When I type, eg. node -v command, it returns nothing. After node I can add anything, it will just be ignored and won't return anything in the next line. I've added C:\Program Files\nodejs to PATH system variable, but it still doesn't work. Only time node -v command works is when I do (in cmd) C:\Program Files\nodejs>cd C:\Program Files\nodejs, then C:\Program Files\nodejs>node -v and in the next line it returns proper verision v16.13.1 .
Obviously, node command works and returns properly only when I run command from \nodejs folder, but as I saw on the Internet, it should work (with system PATH set up) from any folder. I think something is messed up in my Environment Variables, but if you know how to solve this problem, please let me know! Every comment is appreciated!
I downloaded NodeJs from https://nodejs.org/en/download/ (LTS, Windows Installer, 64-bit). Thanks in advance!
PS. npm command works correctly from any folder.
#Compo
Your issue is that you have many things in the %Path%, and clearly have made errors when adding for node.exe.
The first noted problem is that you have added C:\Program Files\nodejs\node.exe when you should have used only C:\Program Files\nodejs. Entries in this variable are for the directories which hold your executable files, not the files themselves. However, as C:\Program Files\nodejs is already included, you can simply remove that invalid entry.
The next issue, is that you need to understand what happens when you enter node in the Command Prompt or a batch file. What happens is that the current directory is searched for files named node which have an extension matching one listed in the %PATHEXT% value, (which is searched in order first to last). If a match is found, that file is run, and the searching stops. If no file is found, the same process occurs with every location listed under %Path%, (in its listing order first to last), the first matching file is run and the searching stops.
So by using node, what happens in your case is the %Path% is being searched, because there is no file named node.COM, node.EXE, node.BAT, node.CMD, node.VBS, node.VBE, node.JS, node.JSE, node.WSF, node.WSH, or node.MSC in the current directory. So each location is searched in order, until it reaches the first match, which in your case happens to be C:\xampp\htdocs\WebRulet\node.JS.
So essentially by using a presumptive/lazy command you are effectively running:
C:\xampp\htdocs\WebRulet\node.JS -v
Which is not what you wanted, and why you are not getting the result you had hoped for.
So now you understand the process which happens, by using code which make assumptions, and how that could cause issues, errors, or potential catastrophies. You should realize with all of that searching, especially if you have many entries in your %Path% and/or %PATHEXT% values, that the quickest and safest way to run your command would be:
"C:\Program Files\nodejs\node.exe" -v
Or
"%ProgramFiles%\nodejs\node.exe" -v
Please note that those absolute paths are double-quoted because they contain space characters. However, spaces are not the only problematic characters used in filenames, so best practice is, unless you are certain there are no such poison characters, to always double-quotes.
Now I know that almost every site will never explain all of that information, and all the code you read will not follow it either, so you are probably going to want to minimize your typing whilst working on the command line.
In order to do that, you will need to ensure that your %Path% value string, is ordered in such a way as your most frequently typed executable file path, is nearer the beginning, than any other location holding a possible matching file. However I will strongly suggest that you always use file extensions, for safety, (it is, after all, usually just four more characters to type).
Noting the entries in your %Path%, there are some extremely important ones missing, which means that your %Path% is essentially corrupted, and requires fixing because it will seriously affect the proper running of your Operating System.
To fix your variables, and order them correctly, begin by typing the following in your Command Prompt window:
Start %SystemRoot%\System32\SystemPropertiesAdvanced.exe
In the window which opens, click on the [Environment Variables] button. A new window will open, within the User variables (upper pane), double-click on Path, and using the [New] [Delete], [Move Up] and [Move Down] buttons make sure that the entries in it, in this order, are:
%UserProfile%\AppData\Roaming\npm
%UserProfile%\.dotnet\tools
%UserProfile%\AppData\Local\Microsoft\WindowsApps
%UserProfile%\AppData\Roaming\Composer\vendor\bin
D:\Inkscape\bin
Once done, click on [OK] to close the window, then do the same thing for System variables, (lower pane), with the following ordered list:
%SystemRoot%\System32
%SystemRoot%
%SystemRoot%\System32\wbem
%SystemRoot%\System32\WindowsPowerShell\v1.0
%SystemRoot%\System32\OpenSSH
%ProgramData%\ComposerSetup\bin
%ProgramData%\DockerDesktop\version-bin
%ProgramFiles%\Docker\Docker\resources\bin
%ProgramFiles%\Azure Data Studio\bin
%ProgramFiles%\nodejs
%ProgramFiles%\dotnet
%ProgramFiles%\heroku\bin
%ProgramFiles%\Oracle\VirtualBox
%ProgramFiles%\NVIDIA Corporation\NVIDIA NvDLISR
%ProgramFiles(x86)%\NVIDIA Corporation\PhysX\Common
%SystemDrive%\xampp\bin
%SystemDrive%\xampp\htdocs\WebRulet
Once complete click on [OK], [OK], and [OK] to close your windows, and then close the Command Prompt window.
From now on you should be able to open any new Command Prompt window and use:
node -v
But remember, I strongly advise that you get into the habit of using its extension:
node.exe -v
Which should result in:
v16.13.1
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.
How can I understand and control from where spawnCommand runs?
I am creating a yo generator and as part of the process I need to call an external tool. The way I am attmepting to do this is by calling a powershell script from spawnCommand. I was having trouble with spawnCommand having spaces in paths, so I just encapsulated that within the powershell file. I saw something about superspawn but couldn't get it to work.
Anyway, my main problem is that I am trying to call powershell and give it the script file as an argument, but it can't find the script file. Here is the code:
signatureKeyFile: function() {
var done = this.async();
this.spawnCommand('powershell', ['sign.ps1'], {
cwd: this.destinationPath('.')
}).on('close', done);
},
I tried using procmon to see what directory it executes from and understand it better. It looks like it tries it in a ton of places, but seemingly all environment paths. It doesn't try the source or destination path for the yo generator, or at least that's how it seemed to me.
So my questions are
1) which working directory does spawnCommand run from by default?
2) How can I contorl that so it can find the this powershell file? spawnCommand won't let me use spaces in paths, so I can't feed it a full path or so it seems to me.
Thanks so much!
spawnCommand won't let me use spaces in paths, so I can't feed it a full path or so it seems to me.
That's usually a well known issues of command line. Arguments are separated by spaces, so it just assume your path is actually multiples arguments.
I'm not 100% for windows, but on OSx, you'd espace spaces as some\ path\ with\ spaces.
Another options is to pass arguments as strings. What if you were to wrap your path in double quotes?
this.spawnCommand('powershell', ['"/home/My Home/sign.ps1"']);
FWIW, Yeoman spawnCommand is just a wrapper for Node spawn command where we help normalize a command so it'll run fine on windows. See
https://github.com/yeoman/generator/blob/master/lib/actions/spawn-command.js#L20
https://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_options
It'll help you to test the correct syntax to pass path if you can reduce the scope of your problem to only the Node spawn command.
[Edited to fix broken link]
We were able to solve it by setting the current working directory or cwd, with the spaces:
this.spawnCommandSync('sn.exe', ['-k', format("{0}\\{1}.snk", this.destinationPath('.'), this.props.myItemName)], {
cwd: 'C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v10.0A\\bin\\NETFX 4.6 Tools'
});
The google app engine cli commands cannot be found in the python sdk. I've already checked the google_appengine file. The shell commands are there, and I already added the app engine file path to the PATH variable. I echo the PATH variable and the directory to the app_engine file shows up, but still shows not found when I try to use a command that's inside the file. If I reference the command directly by using its whole path, the command works, but otherwise it won't. Is there anything else that needs to be done to reference a command in shell?
More error info please,
If I reference the command directly by using its whole path, the command works
I think your python path maybe wrong, Python 2.6 is not supported.
so are you have mulit-version python?
Thank you for your contributions everyone. It turns out the path I was using was wrong. Instead of /home/Programs/Apps/google_appengine it should have been /home/Programs/google_appengine. I guess the shell doesn't check to see if the path you add to the PATH variable actually exists. Who knew? Not me
Until I run into another problem stack overflow--which may be soon
See ya
I'm having the following problem installing Titanium Studio. On my Mac (OSX Yosemite), the terminal shows that I have Node, NPM, Titanium, Alloy etc. all installed and 'callable' from any path. Titanium Studio keeps failing to run because it can't find the CLI.
If I go to Titanium's terminal view, absolutely nothing seems to be installed. Even 'ls', 'cd' etc. cannot be run. Anyone know what I'm missing here? It's like .bashrec never gets loaded or something. Would appreciate any pointers in the right direction,
cheers,
Wittner
Ok. Looks like this had nothing much to do with Titanium and everything to do with my system setup, but this might help others who experience the same symptoms.
Turns out that my .bash_profile was incorrectly set up.
.bash_profile is a batch file which holds information about (among other things) the current path. This file, if it exists, gets run every time terminal is started up. One of my path statements in the file ended without :$PATH
:$PATH concatenates the current path when you are putting a path command in the file e.g.:
export PATH=/etc/bin/
export PATH=/Applications:$PATH
The ':$PATH' at the end of the second statement ensures that the path now contains both /etc/bin/ and /Applications. Without :$PATH, the second line would have set the path to /Applications only, overwriting the /etc/bin/ entry.
So in effect all of the PATH commands before the last one had been overwritten. Terminal could not see where ls, cd or an of those command line tools were. My own terminal worked fine because I had it using ksh (Korn shell) which I had set up with some fancy colours and listing options. When Titanium tried to load a fresh copy of terminal, the PATH was effectively being overwritten and so Alloy, Node etc. where not visible to it.
I fixed up the erroneous PATH statements in the .bash_profile, restarted the app and now Titanium works fine.