I ran the command to install Ember.js:
npm install -g ember-cli
Then when I run:
Ember -v
I get error: "The term ember is not recognized as the name of a cmdlet, function, script file or operable program ..."
I added the system environment variable $NODE_PATH = %AppData%\npm\node_modules
I see ember-cli folder in the $NODE_PATH
This is a newly imaged machine so this may be an issue with my npm setup/configuration. How can I install ember globally?
I added %AppData%\npm (use the full path which in my case is C:\Users\bmackey\AppData\Roaming\npm) to the system Path environment variable. I had to remove C:\Program Files\Microsoft DNX\Dnvm\ from my Path in order to stay under the 260 character limit; hopefully I won't need this. I do not know a way around the 260 character limit.
Now ember -v works.
You need to add the path to the ember.cmd file into the powershell environment variable, note that this is different to the standard PATH environment variable.
For those that don't know, the reason you can run ember (a node module) simply by running the command ember is because when you install ember it create a ember.cmd file in your AppData folder:
this file typically looks like this and just bootstraps node and runs the ember js file:
#IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\node_modules\ember-cli\bin\ember" %*
) ELSE (
#SETLOCAL
#SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\node_modules\ember-cli\bin\ember" %*
)
so when you run ember from your command window or powershell it just looks for a cmd file in its PATH variable. If this doesn't have an entry pointing at the location of this cmd file it won't be able to run it.
To fix this in powershell just run the following:
[Environment]::SetEnvironmentVariable("Path", $env:Path + ";C:\Users\<user>\AppData\npm", [EnvironmentVariableTarget]::Machine)
Most of this is taken from the answer here.
Make sure C:\Users\<user>\AppData\npm is where NPM has deployed your ember.cmd file. I have seen this also deploy in C:\Users\<user>\AppData\Roaming\npm so it can vary.
Related
Yarn's not recognized as a cmd command.
I tried installing it globally with 'npm install -g yarn' and adding a path variable to "C:\Users[user]\AppData\Roaming\npm\yarn".
Any other suggestions?
First thing first, you should check you have 16+ node.js installed and, you can check it with
node -v
If it's valid,
run the npm config get prefix it'll give you a path CTRL+C this path
Open the start search and type in env and then click "Edit the system environment variables"
Modify the Environment variables
Add the copied path to you PATH as new
After this you should be good, but if the PS is cannot load the Yarn run this command
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Here a few things you can try:
You may need to close and reopen the Powershell windows because newly added environment variables or updates to them are not automatically reflected to already open shell windows.
Check if your path is correct: it normally is C:\Users\endo\AppData\Roaming\npm on my PC, not C:\Users\endo\AppData\Roaming\npm\yarn as you mentioned.
Try running yarn.cmd or yarn.ps1.
Try CMD instead of Powershell, see if it works that way.
I m trying to install nativescript, when I do the npm install it works fine but after that when I try to
tns doctor or
tns create
it gives me this message:
The term 'tns' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again nativescript
Someone told me that it is probably something with the environment variables but if so i m not sure what needs to be done
I solved the problem by copying the nativescript node modules to C:\Users\username\AppData\Roaming\npm\node_modules and then creating a file called tns.cmd in C:\Users\username\AppData\Roaming\npm that has the following:
#IF EXIST "%~dp0\node.exe" ( "%~dp0\node.exe" "%~dp0\node_modules\nativescript\bin\tns" %* ) ELSE ( #SETLOCAL #SET PATHEXT=%PATHEXT:;.JS;=;% node "%~dp0\node_modules\nativescript\bin\tns" %* )
and then it worked
I am trying to launch a npm script with a custom argument:
"publish-local": "ng build $PROJECT && cd dist/$PROJECT && npm publish --registry=http://my.local.npm.registry"
This is how I am trying to call it from the prompt:
PROJECT=my-lib npm run publish-local
This is how I have seen it should work on different web sources (for example:here)
Anyway, trying to do that, I get this error:
PROJECT=my-lib: The term 'PROJECT=my-lib' is not recognized as the name of a cmdlet, function, script file, or
operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try
again.
At line:1 char:1
What to do?
Short answer: The example(s) that you've seen that "should work" will only work on *nix. They do not work via PowerShell, nor via Command Prompt on Windows.
Given that you're wanting to pass an argument to a npm-script, whereby that argument is consumed two times in the middle of that script I suggest you consider the following approach instead:
The following suggested approach is very similar to my answer here.
Solution - Cross-platform:
For a cross-platform solution, (one which works successfully with *nix, Windows Command Prompt and PowerShell etc..), you'll need to utilize a nodejs helper script.
Let's name the nodejs script publish-local.js and save it in the projects root directory, at the same level as package.json.
publish-local.js
const execSync = require('child_process').execSync;
const arg = process.argv[2] || 'my-lib'; // Default value `my-lib` if no args provided via CLI.
execSync('ng build ' + arg + ' && cd dist/' + arg +
' && npm publish --registry=http://my.local.npm.registry', {stdio:[0, 1, 2]});
package.json
Configure your publish-local script to invoke publish-local.js as follows:
...
"scripts": {
"publish-local": "node publish-local",
},
...
Running publish-local script:
To invoke publish-local via your CLI you'll need to run:
npm run publish-local -- my-lib
Notes:
Inside publish-local.js take note of the line that reads:
const arg = process.argv[2] || 'my-lib'; // Default value `my-lib` if no args provided via CLI.
It specifies a default value to use when no argument is provide via the CLI.
So, If you were to currently run the npm script without passing an argument:
npm run publish-local
or run it with passing an argument:
npm run publish-local -- my-lib
They are essentially the same. However if you were to provide an argument that is different to my-lib, i.e. one that is different to the default specified in publish-local.js, it will take precedence. For example:
npm run publish-local -- some-other-lib
For a further understanding of this solution I suggest you read my answer that I previously linked to.
The default shell used by npm is cmd.exe on Windows, and sh on *nix - this given solution will work successfully with either.
If you only intend to use/support more recent versions of node.js that support ecmascript-6 features, such as destructuring, template literals then you could refactor publish-local.js as follows:
publish-local.js (refactored using ES6 features)
const { execSync: shell } = require('child_process');
const [ , , projectName='my-lib' ] = process.argv;
shell(`ng build ${projectName} && cd dist/${projectName} && npm publish --registry=http://my.local.npm.registry`, {stdio:[0, 1, 2]});
I develop on Windows using a Linux VM via Vagrant and Virtual Box. I'm trying to figure out how to get the Code Runner extension to run my files on the VM. The biggest hurdle so far is, for a given file, I need to convert from the Windows host path to the Linux guest path.
Background:
The Code Runner extension allows one to map file types to shell commands to run those files. For example,
"java": "cd $dir && javac $fileName && java $fileNameWithoutExt"
tells Code Runner that when I try to run a Java file, it should cd to the directory that contains the file, and compile the file, and then run the compiled file. The mapping from file types to commands is called the code-runner.executorMap which is contained in settings.json. By adding the option
"code-runner.runInTerminal": true
to my settings.json, I can tell Code Runner to run in the integrated terminal. So by simply SSHing into my VM from the integrated terminal via vagrant ssh, I have code runner targeting the virtual machine.
This is where the problem comes in - Code Runner is using my Windows style paths and my Windows file structures as command line arguments to my VM.
For example, suppose my Windows file structure looks like c:\a\b\c\d and my VM has its root in c so that c and d are shared folders. If I want to run a file in d, the command cd $dir will tell my VM to do cd c:\a\b\c\d.
I have thought of workarounds like adding the following to my settings to run python files
"python": "cd \"$(dirname \"$(locate -l1 $fileName)\")\"; python3 $fileName",
This command, which runs on the integrated terminal (the VM) locates and changes to the directory which contains the file which is to be run. It then tells the python3 interpreter to run that file. However, this doesn't always work (e.g. multiple files with the same name), and requires me to update the database that locate depends upon every time I add a file.
There has to be some way to translate my Windows file paths to the paths on the virtual machine (so e.g. c:\a\b\c\d -> /c/d). Perhaps through Vagrant? I would appreciate any help.
I developed a workaround. I would still be interested in a "cleaner" solution.
The workaround is as follows:
Firstly, I wrote a Python script to convert from Windows Paths to paths on my virtual machine. The script takes in the windows path to a file and the file name as arguments.
#pathconverter.py
import sys
windows_path=sys.argv[1]
file_name=sys.argv[2]
path_to_vagrantfile = r"C:\Users\Evan\Google Drive\Development\Vagrantfile"
slashes=path_to_vagrantfile.count("\\")
y=windows_path.split("\\")[slashes:]
linux_path="/vagrant/"+'/'.join(y) + "/" + file_name
print(linux_path)
Thus the following code converts from a windows file location to one on my virtual machine (assuming you saved pathconverter.py at the root of your shared directory, \vagrant :
python3 \"/vagrant/pathconverter.py\" $dirWithoutTrailingSlash $fileName
Therefore, to run most files of various interpreted languages, I just supply the output of this command as an argument to the interpreter. For example, to run a Python script on my VM automatically, I just add the following line to the code-runner.executorMap:
"python": "python3 \"$(python3 \"/vagrant/pathconverter.py\" $dirWithoutTrailingSlash $fileName)\""
Or for Racket/scheme, I just do:
"scheme": "racket \"$(python3 \"/vagrant/pathconverter.py\" $dirWithoutTrailingSlash $fileName)\""
I'm executing this code:
p = subprocess.Popen(['/path/to/my/script.sh','--flag'] , stdin=subprocess.PIPE)
p.communicate(input='Y')
p.wait()
It works when executing it on the shell using "python scriptName.py",
BUT when executing using PyDev in Eclipse, it fails, the reason:
/path/to/my/script.sh: line 111: service: command not found
This bash script "script.sh" contains the following command which causes the error:
service mysqld restart
So "service" is not recognized when running the .sh script from the context of PyDev.
I guess it has to do with some ENV VAR configurations, couldn't find how to do it.
BTW - Using "shell=True" when calling subprocess.Popen didn't solve it.
service usually is located in /usr/sbin, and that this directory isn't on the PATH. As this usually contains administrative binaries and scripts which arn't designed to be run by everyone (only by admins/root), the sbin directories arn't always added to the PATH by default.
To check this, try to print PATH in your script (or add an env command).
To fix it, you could either
set the PATH in your python script using os.setenv
pass an env dict containing the correct PATH to Popen
set the PATH in your shellscript
use the full path in your shellscript
set the PATH in eclipse