How can I run a batch-file uder windows git-bash console.
When I run it I get:
user#DESKTOP-DF012sh MINGW64 /c/project-folder
$ util.bat
bash: util.bat: command not found
It should work if you mention where the bat is.
./util.bat
By default, a $PATH does not include the current folder.
I just tested executing a .bat script that way, and it worked just fine.
Related
I want to run Windows native PhpStorm from within WSL2 and ask it to open the current directory.
JetBrains Toolbox includes scripts to launch their applications from the command line (i.e. phpstorm.cmd). WSL2 supports running windows executables from WSL2, however, this does not seem to work with these scripts.
Therefore, I decided to try:
$ powershell.exe phpstorm.cmd
And this works fine and opens PhpStorm. I then need to tell PhpStorm to open the current working directory.
In Linux, this would be phpstorm . or in windows phpstorm.cmd .
I tried both of these:
$ powershell.exe phpstorm.cmd .
$ powershell.exe phpstorm.cmd pwd
$ powershell.exe -c "phpstorm.cmd $((pwd).Path)"
But neither passed the pwd as the context.
It seems to be an issue with UNC paths not being supported in CMD.EXE:
glen#Sisko:~/repos/gclark18/tdd-dailyjobs$ powershell.exe -c "phpstorm.cmd $((pwd).Path)"
-bash: command substitution: line 1: syntax error near unexpected token `.Path'
-bash: command substitution: line 1: `(pwd).Path'
'\\wsl$\Ubuntu\home\glen\repos\gclark18\tdd-dailyjobs'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
Can anyone advise how to do this please?
I'm using cypress for test automation and when running a test spec from the Git for Windows bash terminal I get weird characters in the results output:
cypress spec run in Git for Windows bash -
If I run cypress from a Windows command prompt the output characters are correct:
cypress spec run in Windows Command Prompt -
I'm using Windows 7, cypress 5.1.0, and Git for Windows 2.28.0 with mintty 3.2.0
Any thoughts on how to correct this?
The issue is described in this GitHub issue.
The problem is that Cypress is sending UTF-8 encoded text through its stdout which is mangled by Windows before being received by Mintty (which is what hosts bash and runs git on Windows).
I understand that Mintty doesn't yet instruct Windows to not mangle the stdout it processes - (cmd.exe does, however, which is why it works there) - but we can do that ourselves by changing our Windows OEM Code Page setting using the chcp program (located at C:\Windows\System32\chcp.com and yes, that's a .com, not .exe). You can add a command to your .bashrc file so it will always run when you fire up Mintty:
Open mintty on Windows - presumably this starts a bash shell.
Go to your home directory (i.e. cd ~)
Open or create a .bashrc file.
Put this in the file (update the path to your chp.com program as appropriate):
/c/Windows/System32/chcp.com 65001
Then restart the terminal window and it should work.
As both #digijay and #Dai replied above the cause of the issue is described here https://github.com/git-for-windows/git/issues/2806
The issue was resolved with the next release of git-for-windows. Prior to the fix being released, I solved the issue for myself by simply running this at the bash command line before running my cypress run command:
> cmd //c chcp 65001
I'm extremely new to Cygwin but I am somewhat comfortable in Linux (I can read man files fine).
I want to create a BASH script using Cygwin that deletes the files in a folder on the shutdown signal given by Windows. If this can't be done, I also could try deleting the files in the same folder on startup. I installed CRON but does CRON only works for scheduled tasks, rather than on 'signals'? Answers would be nice but a general idea of how to proceed would be even better!
I can write the script. I just don't know exactly how Cywgin interacts with the Windows OS in order to perform these procedures.
Another question, how do I run CRON on Windows startup?
If it matters, my O.S. is Windows 10 x64 running Cygwin.
Cygwin.bat, a batch file which was installed under cygwin installation folder will give you hint of how to run cygwin script.
The script contains just:
C:
chdir C:\cygwin64\bin
bash --login -i
to run the bash shell interactive.
Make a copy of Cygwin.bat with another name (Startup ?) and change last line in
bash --login path_to_your_script_here
Put the bat file or a link to in in the Startup folder.
Great thread over here: https://serverfault.com/questions/245945/autostart-cygwin-on-windows-boot-and-run-a-cygwin-command
tl;dr
you can put command directly:
#echo off
C:
chdir C:\cygwin64\bin
bash -c "/usr/bin/whatever"
I installed new version of MSysGit and now I am not able to run *.bat files directly from command line("called MINGW64").
I try to search it, but I only saw options which needs run cmd first.
Out of a git console: how do I execute a batch file and then return to git console?
cmd "/C clean.bat"
Is there some option to just run the clean.bat?
Thank you very much
I solve that by updating all libraries... Maybe Cygwin? I am not sure, but update all your software and it works.
Try this from MINGW command line
$ cmd <test.bat
Try this from MINGW command line
$ eval "./test.bat"
D:\workspace>echo hello world
hello world
I am getting this error "rem:command not found" in my batch file. Other dos commands (e.g. echo) are also not found.
My makefile is calling this batch file. This works previously when I am using cygwin. But when I changed to MSYS, I am getting this error. Anyone know why this is?
I am using MSYS version 1.0.17 on a Windows pc. But, I did not install Mingw. Should i install it also?
It looks as though you are trying to run a "Batch" file using Bash. This will not work. While Batch file interprets rem as a comment, Bash simply thinks it is a command and tries to run it.
My suggest would be to rewrite it as a Bash script, perhaps this could be a starting point.
After trying with cmd //c [path_to_bat file] it works for me.
This is because mingw cannot run *.bat file directly after running *.bat file with cmd it works.
I found following mail thread about this type of issue
https://lists.gnu.org/archive/html/help-gnu-emacs/2003-10/msg00323.html