Git Bash For Windows Free Download
Marilu Lukaszewski
A bit of history, back in 2015 project Astoria was started to bring Android apps to Windows and they built a Linux subsystem called Windows Subsystem for Linux (WSL) for the purpose. Eventually project Astoria was dropped as it undermined their UWP (Universal Windows Platform) strategy, but some parts were retained and form the basis of bash for Windows. Over the course, Microsoft collaborated with Canonical (creators of Ubuntu Linux) to provide them with a native image with all supported tools/binaries.
For the curious WSL solves the problem of running Linux software using different methods than most other options. WSL 1, intercepts kernel calls and translates them to windows kernel calls (think the opposite of Wine). WSL 2 runs a real Linux kernel in a lightweight VM that has access to the Windows filesystem.
Babun is Cygwin with a full-featured package manager (pact), oh-my-zsh for its shell, git, automatic updates and a plug-in oriented architecture. Although the default shell is zsh you can easily switch to bash. It seems like a nice upgrade from vanilla Cygwin if you don't mind the extra weight.
MinGW is primarily a software distribution and a building platform for Windows. In particular it's a Windows port of the GNU compiler tools, such as GCC, make, bash, and so on. It includes a fair amount of GNU tools and a minimal Unix compatibility layer.
Git for Windows is either just MSYS2 with git installed or at least heavily based on MSYS2. It provides the same shell (bash), terminal (Mintty) and package manager (pacman). It appears to be the most popular way to get the dominant Git running on Windows and along with it you get a nice Unix environment.
Except from WSL most of the above tools share a lot of common technology (libraries, executables, concepts). For example the bash shell that comes with MinGW depends on msys-2.dll which itself is a fork of cygwin.dll. So yes there's plenty of room for confusion :-)
Cmder provides just a nice terminal and a bash-like shell for Windows. It's main component is Conemu (the terminal). On top of that it adds Clink which provides Powerful Bash-style command line editing, a custom prompt layout and the Monokai color scheme. It is highly (or maybe fully) compatible with native windows console programs.
Scoop provides a command line package manager for many well known cross-platform programs including many GNU tools. It downloads pre-compiled packages. It does not provide neither a shell nor terminal but instead runs under windows' cmd.exe (with all its limitations but also with its full compatibility with native windows console programs). It also includes no compiler suite (but of course compilers and development tools are typical packages you can install with scoop). A lot of the programs that Scoop installs either come directly from the MinGW/MSYS project, or were built using their tools.
Gow (Gnu On Windows) is the lightweight alternative to Cygwin without a shell. It uses a convenient Windows installer that installs about 130 extremely useful open source Linux applications compiled as native win32 binaries and available through windows' cmd.exe. It is designed to be as small as possible (about 10 MB).
Mintty is the terminal used in Cygwin, MSYS2 and their derivatives. One should be aware that if you're running windows native console programs it is not a painless replacement for the Windows Command Prompt. While programs with simple text output usually work fine, interactive and full screen ones often have problems. Read more on Mintty's home page and also read the entry "Some native console programs don't work when run from Git Bash" on Git for Windows FAQ. That entry has this recommendations to make when you face this kind of problems:
The issue of Linux commands shadowing windows ones is a common cause of hard to debug trouble in solutions like Cygwin/MSYS2/MinGW. Here's an example: I had a .bat file that was using the timeout command. When run under Cygwin it would fail because timeout is also a Linux command but with different syntax. After I've spotted the issue I found out I could add a PATH=... at the top of the .bat file to make sure the windows command had priority. But then I got an even more cryptic "Input redirection is not supported" error and settled for a workaround before finding the reason.
I am using some linux only R packages. I built and can successfully run them in wsl2 bash (I have ubuntu 20.04 installed, if that makes any difference). I would like to use the Rstudio IDE on windows to send those directly to R in WSL2.
I am currently using vim editor on Git Bash terminal running in a Windows machine, but I want to switch over to Emacs editor. It is returning bash: emacs: command not found . Do I need to install the Emacs? If true, what command do I use, and what could be the general soulution?
This morning I saw a colleague working in Git-Bash and the good-old-fashioned "windows command line" and I thought to myself, why doesn't he "just" use Windows terminal? So, I showed him Windows Terminal and he was impressed. First thing he asked then, was if it would be possible to add Git-Bash as a tab. Wel yes, I thought... and I immediately showed him how this can be done via the settings of Windows terminal. At that moment, I didn't realize that this would result in a blogpost ?. I discovered pretty quick that there was a catch and in this post, I want to show you what I did, why it didn't work and finally, how you need to approach this.
All you need, or so I thought, is to add the exe of Gi-Bash to a new windows terminal profile. The idea is that I first found a suboptimal solution (out of a naive approach), which I'll explain first. After that I'll show the correct approach!
After that, we just have to validate our new profile by opening a new tab by clicking on the "downward pointing arrow" and and then on the newly created "Git-Bash" profile: As you can see, the behavior is not at all what we expect as Git-Bash opens in a new window instead of a new tab! This is strange, but not a huge problem. After looking around for a bit, I discovered that there is also another set of exe's sitting in the folders next to the one containing git-bash.exe. It didn't take me very long to figure out that the correct exe that needs to be referenced is this one: C:\Program Files\Git\bin\bash.exe (This one is in a subdirectory of the initial one and does, to my knowledge, the same)
today I've started to use the great ssh feature of 1password. When I use the git fetch command the terminal asks the credentials (windows hello) then when I want to use the git fetch again the terminal again wants me to authenticate myself (the situation is the same for all commands which want to use my key).
It consists of a command line terminal calledmintty, bash, version control systems like git andsubversion, tools like tar and awk and even build systems like autotools, allbased on a modified version of Cygwin. Despite some ofthese central parts being based on Cygwin, the main focus of MSYS2 is to providea build environment for native Windows software and the Cygwin-using parts arekept at a minimum. MSYS2 provides up-to-date native builds for GCC, mingw-w64,CPython, CMake, Meson, OpenSSL, FFmpeg, Rust, Ruby, just to name a few.
Now i want to use the "Windows Subsystem for Linux" feature in Windows 10 instead of Cygwin.I made sure the PRTG service runs under the same user as i used to setup WLS (Ubuntu).I changed the batch file accordingly "'c:\cygwin64\bin\bash.exe -l -c" -> "'c:\windows\system32\bash.exe -l -c" and verified it's working by executing it in cmd terminal.
Unfortunately i only get an error message in PRTG (response not well formed)"Antwort nicht wohlgeformt: "(Der Befehl "C:\Windows\System32\bash.exe" ist entweder falsch geschrieben oder konnte nicht gefunden werden. ECHO ist ausgeschaltet (OFF). )" (Code: PE132)"
THX for the reply, but i think you misunderstood my "problem".I have no issue calling a program / scrip with additional parameters.It's just that running a batch scrip callung bash.exe fails while running bash.exe directly works.The issue with directly running bash.exe is that i have to provide more parameters that are the same for all custom script sensors.
Hey Dariusz,
with Cygwin i used PRTG > -BAT File > bash.exe
I would like to keep it that way using WSL, but i only get the above mentioned error.
So currently i use PRTG > bash.exe
If i use PRTG > bash.exe i need to call it like that:
Hi there,
Most likely the reason for the error is, that the script is executed under the SYSTEM user and the directory where the batch starts is "C:\Windows\System32\". So in this case when you only call "bash.exe", the commandline expects this exe to be available in the very same directory. Could you check if the "bash.exe" is really present in the "C:\Windows\System32\" directory?
Best regards.
Please read these instructions all the way through before starting theinstallation.
- Install or update to Windows 10
- Enable and run the Linux Bash shell
- Install additional packages
- Install and run Xming
- Download NCL
- Install NCL
- Set your environment to run NCL
- Set DISPLAY environment variable
- Test NCL
- Troubleshooting problems
- Open a browser window from the Linux shell (using the above instructions from PC World).
- Go to the Climate Data Gateway web site.
- Navigate your way to the NCL Version6.6.0 OPeNDAPenabledor non OPeNDAP enabledpage.
- Download the binary for the 64-bit version of NCL compiled under Debian 7.11:ncl_ncarg-6.6.2-Debian7.11_64bit_gnu472.tar.gzorncl_ncarg-6.6.2-Debian7.11_64bit_nodap_gnu472.tar.gz
- If you get an error about "ncl" not being able to find a missing"libxxxx.so" library, then try using the "apt-get" command toinstall that library or package.
- If you get the error: warning:GKS:GOPWK: --X driver error: error opening displaythen this probably means that your DISPLAY environment variableis not set, or it is set incorrectly. Please type:printenv DISPLAYand make sure that it is set to what is discussed in the "Set DISPLAY environment variable" sectionabove.