I have installed nodemon globally,but while trying to run it's showing the error as in image. What to do? Also my node js and projects are in different drives.
There are many of this type issues when you search for them. The best guide I found is:
https://dev.to/thetradecoder/how-to-fix-error-nodemon-ps1-cannot-be-loaded-because-running-scripts-is-disabled-on-this-system-34fe
Step 1:
Open Windows PowerShell with Run As Administrator.
Step 2:
As you see the error is about_Execution_Policies, first to see what's there in the present execution policy. Use this command on Windows PowerShell to get it
Get-ExecutionPolicy
Here you'll see 'Restricted'. So, this is the main reason- running scripts on this system is 'Restricted'.
Step 3:
Now we need to change this policy to allow the operation. Use this command to make it Unrestricted -
Set-ExecutionPolicy Unrestricted
Here you'll get a prompt message. Press Y to change it
That's it. To ensure, you may check the execution policy status by this command again
Get-ExecutionPolicy
You'll get the output 'Unrestricted'
The problem is solved. Now you can use nodemon on your machine.
Related
TL;DR
I cannot execute commands such as tsc unless I include npx before it (e.g npx tsc). How can I fix this?
The title is a bad explanation of the problem I have.
Say I have installed an npm package with a CLI with it (typescript in this example). And the CLI is used like
tsc <filename> or just tsc. But whenever I try to do it like that, I get an error like
'tsc' is not recognized as an internal or external command,
operable program or batch file.
But... when I do
npx tsc
then it works!
So whats the problem?
The problem with doing npx tsc is because
npx is slow at executing commands
its annoying having to type npx and the front of every command.
And the thing is, this was originally not a problem with WSL.
Why dont you just use WSL?
I have always had problems with WSL (primarily permission issues due to security reasons) and so I uninstalled WSL and just used command prompt. I would have perferred using WSL but it was simply not an option.
Other Info:
I am using Windows command prompt.
I have installed the packages globally
So is there a way to just execute commands that way or is it Command prompts fault?
! this only works for Windows !
Ok, so I came across this post and thankfully, the first answer there was the solution!
Just add %USERPROFILE%\AppData\Roaming\npm to the path variable in system variables!
To access the system variables, press the Windows key, type Environment variables and click on Environment variables at the bottom of the window. The path variable can be found under User variables for (profile name).
When I press Ctrl+C in PowerShell, I receive:
Terminate batch job (Y/N)?
Similar to https://superuser.com/questions/35698/how-to-supress-terminate-batch-job-y-n-confirmation, except for Windows PowerShell.
Does PowerShell provide any more control over batch jobs than what CMD does?
The behavior is neither caused by PowerShell nor can PowerShell change it (as evidenced by the PowerShell source-code repo not containing the prompt message).
The behavior is built into cmd.exe - Powershell, in this case, is calling a .cmd file (batch file), which is interpreted by cmd.exe.
If you explicitly control the invocation of the target executable, you can fix this by moving to Powershell - note this has its own considerations, see below.
If you do not explicitly control the invocation of the target executable, you're out of luck (unless you're willing to install third-party cmd.exe replacements) and must press Ctrl+C twice in order to terminate execution.
A[n ill-advised] workaround is to modify the cmd.exe binary - see article with instructions on how to patch the cmd.exe executable in order to suppress the prompt. Additionally, you can post a feature request on GitHub to request that this behavior be fixed at the source, though that is unlikely to happen for reasons of backward compatbility.
To demonstrate the behavior:
The examples assume that Node.js is installed and that node.exe is therefore in your PATH:
First, invoke node.exe directly, with a tight loop that requires you to press Ctrl+C to terminate the process.
PS> node -e "while (true);"
As you'll see, pressing Ctrl+C instantly terminates the process - no confirmation prompt.
Now, let's create a sample batch file that invokes the same command and invoke that batch file:
PS> "#echo off`nnode -e `"while (true);`"" | Set-Content test.cmd
PS> ./test.cmd
As you'll see, pressing Ctrl+C now presents the undesired Terminate batch job (Y/N)? prompt. (You'd get the same behavior if you ran the batch file from cmd.exe.)
To demonstrate that gulp is a cmd file:
You say you're running your command via gulp's CLI.
On Windows, the entry point for the gulp CLI is gulp.cmd [see update in the bottom section] - i.e., a batch file. That is how it works in general for npm-package "binaries" (executables) implemented as either JS files or shell scripts.
That gulp invokes gulp.cmd can be verified as follows:
# Execute from a project folder that has `gulp` installed as a dependency.
# If `gulp` is installed *globally*
# Note: CLI `npx` requires npm version 5.2.0+
PS C:\some\NodeJs\project> npx where gulp
You'll see something like:
C:\some\NodeJs\project\node_modules\.bin\gulp
C:\some\NodeJs\project\node_modules\.bin\gulp.cmd
Note that where.exe also lists the extension-less Unix-shell script, ...\gulp; however, from cmd.exe / Powershell such a shell script isn't directly executable, and it is ...\gulp.cmd - the batch file - that is executed.
(If in doubt, place a command such as #set /p dummy="Press a key" at the start of the gulp.cmd file, and you'll see that this command executes when you invoke gulp without the .cmd extension.
Also note that there is no gulp.exe.)
More generally, on Windows, a project's node_modules\.bin subfolder contains pairs of CLI entry points for the CLIs that come with packages that the project depends on locally:
node_modules\.bin\<some-cli> is the Unix shell script (whose executing interpreter is controlled via its shebang line).
node_modules\.bin\<some-cli>.cmd is the helper batch file for Windows.
Updates and future considerations:
In the context of npm modules, the problem would go away if a PowerShell script (*.ps1) were used as the helper script on Windows. There are tickets for npm, yarn and similar software to do this. There are also some drawbacks:
*.ps1 files aren't directly executable from outside of PowerShell, notably from cmd.exe and File Explorer (and changing that is nontrivial).
PowerShell still hasn't fully replaced cmd.exe as the default shell, as of Windows 10 (and won't anytime soon, if ever).
When called from PowerShell, a *.ps1 file would be found and run in-process, so a possible solution is for the npm project to also provide *.ps1 helper scripts, which would take precedence over *.cmd files of the same name.
Update:
Recent versions of npm (verified in 6.14.10) indeed DO install such *.ps1 files.
Alternative package manager yarn, since v2 does not seem to use batch files anymore at all, so the original problem is bypassed there; (v1, by contrast, still uses batch files (only); upgrading from v1 must be done on a per-project basis see the migration instructions).
As the other answer notes, the correct fix is to replace cmd scripts with ps1 versions.
However another workaround for users of the Hyper shell is 'Hyper yes', a plugin that automatically hits y for you when the prompt comes up.
best way to avoid it is to not start it, in my case, is not to type npm run devStart but instead type nodemon ./server.js localhost 3000
here's how it looks like
#echo off
start /w "" "C:\myfile.bat" 2>nul|findstr /i "termin"
if errorlevel 1 goto bypass
:bypass
echo hello by stexup YouTube channel!
timeout /t 5 >nul
I installed Tortoise on Windows 10 (my user had admin privileges but installer wasn't ran as admin), and when trying to use any tortoise contextual menu, I was getting this error:
"TortoiseProc Launch failed: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail."
I verified, "run as Administrator" was not checked for TortoiseProc.exe file. I tried to check it, but this didn't change anything.
So I decided to uninstall it, and install it again. And then I was having this error:
a dialog saying the TortoiseProc.exe requires elevation
Now, when attempting to run the app by double clicking on TortoiseProc.exe, I got a prompt saying this app required privilege admin. Clicking on OK ran it properly. So I guess the prompt isn't displayed when calling it from a contextual menu, and it silently fails.
I fixed the problem by right clicking on TortoiseProc.exe file -> proporties. Then, on the Compatibily tab, I clicked on "Run compatibility troubleshooter". And voila! It fixed the problem: TortoiseProc.exe now runs, and does not ask any admin rights!
Run the Command prompt (cmd.exe) with admin rights and run this command:
SxsTrace Trace -logfile:SxsTrace.etl
Now run the Tortoise program which causes the SideBySide error.
Go back to the command prompt press ENTER to generate the SxsTrace.etl. Now type this:
sxstrace Parse -logfile:SxSTrace.etl -outfile:SxSTrace.txt
Now open the SxSTrace.txt trace and look which VC++ runtime is missing. Go to Microsoft.com, download and install the required version.
If you are unsure, please upload the complete SxSTrace.txt here.
I am creating an installer for a Windows application that will be run daily at midnight. I am attempting to schedule the task by running the following command after all files have been installed:
schtasks.exe /create /tn "My Task Name" /xml "path/to/file.xml"
However, no task was created when I ran the installer. I opened command prompt and tried typing in the command manually to see what went wrong, and the only output I received was ERROR: Access is denied. I followed the suggestions of others and added the /ru switch, but even after entering the correct password, I still received the access denied error message. I found this answer, which involved modifying the registry using a program called SubInACL, which might work, but would probably be a bad idea, since this would have to be installed and run on all end users' machines just so that the task can be scheduled in the first place. Is there any other way to schedule a task through the command line, or will I have to use something other than Task Scheduler?
Okay, the problem was that running schtasks.exe from the [Run] section caused it not to be elevated to the Administrator level. I used the Exec() function in the [Code] section, and that made it run with Administrator privileges, which solved the problem.
I recently reinstalled Cygwin on my computer in order to get access to several command line elements that I was missing. I have never had previous difficulty with Cygwin, but after this reinstallation, an error message continues to appear after (almost) each command entered. For instance:
-bash-4.1$ wc m1.txt
3 [main] bash 2216 child_info_fork::abort: data segment start: parent(0x26D000) != child(0x38D000)
-bash: fork: retry: Resource temporarily unavailable
2013930 4027950 74968256 m1.txt
Generally, the command still runs (as seen above), but not always. Occasionally, the 'error' message occurs several times in a row (the initial number "3" will then change to a "4" or "2", notably if I start a second Cygwin window.
Also, as soon as I start up Cygwin, I get the following message before the prompt:
3 [main] bash 6140 child_info_fork::abort: data segment start: parent(0x26D000) != child(0x36D000)
-bash: fork: retry: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash-4.1$
At the moment, I am debating whether to uninstall/reinstall Cygwin again or just live with the error messages, but I was curious if there might be an issue that I am unaware of.
(assuming Cygwin is installed at C:\Cygwin):
Open Task Manager and close any processes that look to be Cygwin related.
Open C:\Cygwin\bin in Windows Explorer
Verify that dash.exe, ash.exe, rebase.exe, and rebaseall exist in this folder
If any of them are missing, re-run Cygwin setup and select the dash, ash, and rebase packages
right-click your C:\Cygwin folder, uncheck Read-only (if its checked), and press OK.
When an error about not being able to switch some files comes up, select "Ignore All". Wait for this process to complete.
Browse to C:\Cygwin\bin in Windows Explorer
Right click dash.exe and click "Run as Administrator". A command Prompt should appear with nothing but a $
Type /usr/bin/rebaseall -v, hit enter, and wait for the process to complete.
If you get errors about Cygwin processes running, try Step 1 again. If that still doesn't work, Restart your computer into safe mode and try these steps again.
A commenter noted that, depending on your settings, you may have to type cd /usr/bin && ./rebaseall -v instead.
Try opening Cygwin again.
This process worked for me. I hope it works for you guys too.
Source: http://cygwin.wikia.com/wiki/Rebaseall
I would like to add the following to the above answers, as it is what I had to do after reinstalling Cygwin:
Navigate to the "/usr/bin" directory (usually, C:\cygwin\bin) and right click, Run as Administrator the file: dash.exe
Then, at the $ prompt type the following, hitting enter after each line:
cd /usr/bin/
/usr/bin/peflags * -d 1
/usr/bin/rebaseall -v
What it does is, it marks the dll's as "rebase-able," and then rebases them. You have to have peflags.exe in addition to the above files (in previous answers). You may have to restart windows after doing this and you will definitely need to make sure that there are no processes nor services belonging to cygwin running. (Use task manager, kill any related processes, and then under the services tab look for any service starting with CYG and stop it.)
After doing this, I was able to get cygwin to run without any errors about dll's being loaded to the wrong addresses aka fork errors, etc.
I hope that this helps others, as it was a pain to find.
SOURCE: http://www.cygwin.com/faq.html#faq.using.fixing-fork-failures
and the rebase README file.
To add on to other answers here, we ran into the same issue but could not run the rebase command from the ash or dash shell. However, when launching the command from the Windows cmd shell, the following worked.
cmd /c "C:\cygwin64\bin\ash.exe /usr/rebaseall -v"
-v is to get verbose output
I found another information here :
http://cygwin.com/ml/cygwin/2014-02/msg00531.html
You have to delete the database at
/etc/rebase.db* and do in a "ash" windows :
peflags * -d 1
rebaseall
It works for me on 2 servers.
I solved this problem by restarting my computer. Probably installed a driver update and kept using sleep instead of shutting down.
Experienced the same issue when loading Cygwin with cygiconv-2.dll forking and not loading successfully in the Cygwin terminal, but after turning off my AntiVirus (it was specifically Ad-aware), the issue resolved, and Cygwin worked properly.
In case you are using babun's Cygwin, after rebaseall, try launching Cygwin by executing .babun\cygwin\cygwin.bat in a Windows command prompt or Windows explorer.
This works for me (while launching babun's default console - mintty results in fork error).
I had the error on win10 and i was trying to rebase to c: before install.
then i saw that the installer was installing it instead to c:/Users/myuser
so i was coping all files from c:/Users/myuser to c:.badun
and then restart plus open badun.bat
not shure if this was wise its now duplicated XD... but then it worked again.
Rebaseing didn't help in my case. In addition to what other people suggested, I noticed that reducing the length of PATH environment variable fixed the issue for me (and for other people as well as can be seen from this answer).
This issue is intermittent in nature & I found this issue when there is network is too slow to connect to remote machine on AWS.... I have Shell script that runs through Gitbash shell & it connects to AWS EC2 instance with ssh..... Most of the time, it ran correctly but 2 out 100 times it get into this issue bash: fork: retry: Resource temporarily unavailable .... Killing the MSYS2 terminal from task manager helps to overcome with this issue....
Negative side is you need to run the scripts from the beginning...
I had the same issue on Windows 10 and the mobaxterm app (which uses cygwin) and I tried all of answers listed here however for me, the solution was to simply delete the "CryptoPro CSP" application.
I started facing this problem after upgrading to windows 10. As of now I do not see that any of the above method working.
What I am noticing is that if you start cygwin with admin right (right click and say "run as admin") then it works fine.
Or you open cmd as administrator and then launch cygwin from there, then also it runs fine.
Just reinstall cygwin and select TCL and activate EXPECT