12 ms·

Git Bash is my preferred Windows shell

229 points by indigodaddy 2y ago

sevensor 2y ago
Its biggest advantage is how easy it is to convince corporate IT that you need Git for Windows, compared to msys2, Cygwin, or WSL.
- xeromal 2y ago
  So Say We All!
- mid-kid 2y ago
  This, corporate has been insisting on using ThreatLocker to block almost everything from running - Git For Windows is the only comfortable environment remaining, at least until I can convince them that this is stupid.
- jfdjkfdhjds 2y ago
  gitshell is a opinionated msys2 install. they just picked one of the variants and removed the package manager. this could serve as a wake up call to msys2 maintainers. every time i install it, i have absolutely no f ideia what the 6 variant icons mean and I couldn't care less since all of them mostly work... (thankfully I don't use windows much to reach a point the difference matters?) it's very overdue they just pick one and keep the others with better names in a compatibility folder or something. also, a better name.
  - sevensor 2y ago
    If you’re not sure, you probably want UCRT64. At any rate I used it to pull a rabbit out of a hat at work by building some software with it that didn’t have an official windows build.
    - chrsw 2y ago
      Building in the URCRT64 environment means the executables wont run on versions of Windows older than 10 without extra runtime support, I think. So that's something to watch out for.
- deleted 2y ago
  [deleted]
NelsonMinar 2y ago
git bash is very cool. It's based on good ol' MSYS2 and MinGW which has always been a nice way to do minimalist Unix-like stuff in Windows. WSL2 is great these days and can interact fine with Windows files (despite what this article says). But it's a lot more stuff, a full Linux install in a VM.
- exac 2y ago
  I just had an IDEA nx plugin crash my editor until it was removed because it can't handle WSL directories, so I would not say it can interact fine.
  - okl 2y ago
    Tip: Install the IDE inside WSL2. Should also run somewhat faster, especially any operation which has to do with many small files, at the expense of a tiny bit of latency in the GUI.
- gchamonlive 2y ago
  > a full Linux install in a VM Really? I always thought the subsystem worked translating OS calls back and forth without virtualizing an entire machine. It sure has an entire OS, kernel and all, but not a virtualization layer. Maybe that was the case for WSL but not WSL2?
  - akdev1l 2y ago
    That was WSL1 and as a result had a bunch of unimplemented syscalls. Microsoft realized trying to keep up with the ever-growing list of syscalls on Linux is actually not practical hence they opted for the virtualized approach with an actual Linux kernel to achieve 1:1 syscall compatibility. They released that as WSL2. Technically the name is not accurate anymore as there aren’t any “subsystems” at work anymore.
  - deleted 2y ago
    [deleted]
  - jborean93 2y ago
bena 2y ago
It's weird, I mostly associate git bash with VS Code because it's the terminal I use most often with it. It doesn't occur to me to use it outside of that context. I use the command shell or Powershell depending on what I need to do.
delta_p_delta_x 2y ago
> I like Git Bash because… > I’m more comfortable with bash commands than CMD or PowerShell commands (because I’ve been using Bourne shell (sh) and friends for more than 30 years). This is the only argument I'm willing to accept, and honestly it's the only argument the writer needs, really: un-learning 30 years of experience to use something else even if the latter is objectively superior, would be a pain in the neck for anyone. That being said I believe that seriously attempting to use the native tools would help the author understand Windows at a more fundamental level. Also, this does raise a few questions, though—if the writer has been using UNIX shells for that long, why are they using Windows at all? As I commented elsewhere, why shoehorn the whole set of UNIX core utilities and binary utilities onto Windows when the latter comes with its own shell, command-line utilities, and management tools? More importantly, the author going by the rest of their posts (assuming it was the same author) doesn't strike me as the type (i.e. normie, for lack of a better word) to use Windows as a daily driver, but they seem to use it all the same. Therefore, why not an OS where these utilities feel more native and more useful, like Linux or one of the BSDs? In contrast to the author I've been using and programming almost nothing but Windows (with a brief stint on Linux in university and now at work, but only for work), and on Windows I use PowerShell and if I really need to, CMD.exe (good riddance). As far as compilation goes, I use Visual Studio with MSVC and Clang-Cl, because they are the only complete development environment for Windows—all the others (MinGW, Cygwin, MSYS2) are incomplete or worse in some way, or make life harder than necessary in some way. > I have experience using Windows PowerShell (powershell.exe), but do not yet have experience using the cross- platform PowerShell Core (pwsh). For the record, functionality between powershell.exe and pwsh.exe is almost identical, with some minor differences[1]. Additionally they differ in the .NET runtime they were written against (.NET Framework 4.8 for powershell.exe, and .NET 7 and later for pwsh.exe). [1]: https://learn.microsoft.com/en-gb/powershell/scripting/whats-new/differences-from-windows-powershell?view=powershell-7.4 https://learn.microsoft.com/en-gb/powershell/scripting/whats...
- jaaron 2y ago
  > why are they using Windows at all? In my case: - I had 10+ years of experience in linux/unix development - Career change to AAA game development which is predominantly Windows based - Day to day do Unreal C++ developing in Windows with Windows toolchains - Still use WSL (and thus bash) for everything else, including DevOps related work, cloud/container development work, and personal notetaking/productivity via emacs+org-mode. So, some of us have reasons to co-exist in multiple OS's. I tend to write up scripts in Python if I can so that there's at least a chance that I can run them in both Windows + Unix environments.
AdeptusAquinas 2y ago
Huh, didn't know it was basically bash commands for windows - I thought it was a faked up linux environment. I mostly just use ubuntu under wsl2, though the file performance across the windows filesystem isn't the best.
veltas 2y ago
mintty is a great TTY emulator for Windows
amatecha 2y ago
Oh yeah, I've been using Git Bash for years, it's great. It's nice being able to use a set of basic cli utils I'm used to (gnu utils) which are bundled in (not sure if it's 100% exhaustive in that regard, but still enough for me to do everything familiar). And yes, agree with and have benefited from every single bullet point TFA mentions!
- indigodaddy 2y ago
  mobaxterm has the basic cli tools as well perhaps even more so than git bash. For example it additionally has rsync and I think mc too
pauliusj 2y ago
Coming from mac to windows, a big surprise was how ridiculously slow printf is on any of the ms terminals (cmd, powershell, windows terminal). Git bash does not have this problem when you are running something pretty verbose yet want to view the output in the terminal
mid-kid 2y ago
My favourite shell environment for windows thus far is combining Git For Windows with scoop[1]. A simple "scoop install git" will get the environment installed, and give you a bash shell and full access to all sorts of windows-native utilities from scoop. Some would say I'd be better off with msys2 or cygwin, but the former is meant more as a development environment and lacks misc utilities, and the latter has what is possibly the worst package manager that is still in use (and generally less stellar integration with windows programs). [1]: https://scoop.sh/ https://scoop.sh/
- wilsonnb3 2y ago
  Any reason to choose scoop over chocolatey, which has been around forever, or winget which is included in windows these days?
  - speilberg0 2y ago
    scoop generally installs to your local data, so most programs don't require admin access.
  - beart 2y ago
    Scoop favors portable installs and typically manages upgrades and migrations for you. It does support non portable tools but these live in a different bucket. Chocolatey, and to a greater extent, winget typically defer to the individual applications. In my experience they are more like glorified download indexes than actual repositories for managing software.
  - amenhotep 2y ago
    When I tried using chocolatey, you had to pay them in order to specify a default install directory rather than needing to include it explicitly in every command. I don't know if this is still the case but I formed a deeply held grudge over it. When I tried using winget, it mostly worked quite well, but occasionally would fail horribly. It'll happily detect and offer to upgrade programs that were installed outside winget, for example - great feature!! - except one time when I tried doing this it installed a new instance to a default location instead of upgrading in place, so now I had two installations. I don't trust it. Scoop is simple and sensible and just works in exactly the way I expect it to. With the exception of needing to install scoop-search.
dietr1ch 2y ago
Same, but NixOS is my preferred Windows too.
lynguist 2y ago
In this article I learned that _start_ is the equivalent of _open_ (from Mac). I didn’t know _start_ before.
righthand 2y ago
Honestly there are so many differences and little things on Windows that make using any of the CLIs not worth it. You will run up against gotchas developing on native Windows cmd, Powershell, git bash, and WSL. I left for Linux a long time ago and never have had to look back at the utter mess that is Windows. People stay on that platform for what? A graphical menu in the corner? Compatibility you don’t actually need? Use a real shell and OS and save your sanity.
johnea 2y ago
Why not just ditch the "windows" part entirely, and work on an OS that's not designed for the purpose of exploiting you as a user?
- philipwhiuk 2y ago
  Speaking personally, it's because the company only supports Windows for everything else.
- gruturo 2y ago
  For a lot of people, this is your employer's choice and not yours unfortunately. I jokingly remark that most of my contacts with microsoft products are non consensual.
cafard 2y ago
I was just using Git Bash to run grep...
- Tempest1981 2y ago
  And ripgrep
JackMorgan 2y ago
As a long time personal and professional Linux user, lately my work has led me to work for companies that are Windows-only. I use git bash as my main shell on Windows. It just works for what I need, and in the rare cases I need powershell I just open that. Most of the windows-based programmers I interact with don't know powershell any better than I do. They use GUI tools for interacting with git and the filesystem. So for me, git bash for git and filesystem interaction is a superpower in these places. I could learn powershell, and I'm pretty sure it's much better than bash for scripting, but I'm almost never really scripting in bash anyway, I use tools like F# for that. Powershell seems fine, but it's less well supported on Linux and I don't really need a shell based language. So in the end, git bash keeps on working and I can focus my learning elsewhere. It's stable, still works the same way 15+ years later, so no need to change.
- oldsecondhand 2y ago
  Another thing to consider is availability: many companies don't even allow powershell for dev users.
- bena 2y ago
  Powershell lets you install extensions and run commands against the clr. It’s basically a clr repl. If you need to interact with windows/microsoft specific things (i.e. Active Directory), it’s pretty convenient
- deleted 2y ago
  [deleted]
nikau 2y ago
Gitbash is handy for simple things, but it's a slug compared to wsl2.
niobe 2y ago
Well I took a different route. Always beem 'forced' to use Windows as my workstation by a couple of specialty apps without Linux alternatives that need direct hardware access. But have always used linux on everything else (servers, even my media centre). Because I'm sometimes a late adopter of new tech, until recently I used cygwin as my normal command prompt. There were few downsides to that if you just need access to unix tools, except package management is a bit annoying. Well, discovered the MS Terminal and WSL this year, and happily moved off cygwin. More recently decided to switch over from WS1 to WSL2 but still evaluating the move. Now I have a unix "more native" environment AND a linux distro I'm familiar with. I've been accessing the Windows filesystem under /mnt for two decades so this is normal for me, and if filesystem access is slower, it's not a dealbreaker. All my existing scripts were trivial to update. The integration of WSL and VSCode is also pretty cool. It means my vs code environment environment is also working natively in my WSL distro. Overall can understand some lingering negativity about MS efforts in this dept but after years of rejecting all things linux and open source, in general the 180 from the top is much appreciated and it has kept me on Windows a while longer...so mission accomplished microsoft. Just gotta do something about those pesky apps I still need...
rr808 2y ago
The reason I used to use Git Bash was to ssh to Unix boxes. Since Windows Terminal came out I dont use any more, Windows Terminal is much better.
- Ayesh 2y ago
  The post is about the shell; Windows terminal is only... Well ... A terminal.
  - jborean93 2y ago
    And ssh is a binary so isn’t fully shell related :)
- fud101 2y ago
  its good but it has that bug with tmux that can be very frustrating.
locusofself 2y ago
I started using Linux in 1997. I've been working at Microsoft for a little over 4 years. There are some annoying things about Powershell (verbosity and slow loading of tab completions etc), but in some ways it's vastly superior to bash, as it deals with structured data and not just strings you have to parse, and it has an extremely powerful standard library API (.NET) at your fingertips. I still love bash and use it as well. But the hate powershell often gets is misguided.
- irunmyownemail 2y ago
  Bash rocks because it is about the user and the OS. Powershell is about one thing, Microsoft and the ugliness of ItS CumBerSomE-SynTaX Du-Jour is proof.
  - psd1 2y ago
    Bash is about the user? Are you serious? It's about what twenty people could sling together and make work on a Vax in the 80s in 4Kb. Powershell has regular syntax, legibility, a high degree of discoverability, and included batteries for things that bash victims reimplement again and again. It may not be the best shell for your purposes - it certainly won't run in 4Kb - but it wipes the floor with all legacy shells for usability. You're welcome to have an aesthetic opinion on the syntax, but you must be dead inside if you can look at an average bash script and not recoil in horror. Argument parsing? sed? Control statements? Quoting and escaping? "It's all about the user" is it fuck, you're on drugs.
- lnxg33k1 2y ago
  I feel it's nice to have the power of choice, I can deal with structured data in bash as much as I need, whenever I need, with awk, but it isn't there when I don't
- airtonix 2y ago
  [dead]
- skinner927 2y ago
  There was a time in Powershell’s life when stdout redirection to a file (>) would write UTF-16, then that changed to UTF-8 with BOM and now it’s UTF-8 no BOM. During those times some PS versions would allow to change this globally, some would not. Even if you could change it globally, the names for the same encodings have changed. PowerShell 5.1 “UTF8” actually meant “UTF-8 with BOM” PowerShell 7 “UTF8” meant no BOM. If you read a file in PowerShell that does not have a BOM it decodes it as ANSI. Yes, ANSI, not Ascii. Which is a hilarious choice because you can’t even write an ANSI file in PowerShell. The closest encoding you can use is “Default” which will use the system default but your systems default might not be ANSI. PowerShell is a hot mess. Go read the official docs for character encoding[1] if you don’t believe me. I have CI scripts that have to use .NET calls[2] in PowerShell to write ssh keys to disk because it’s impossible to write utf-8 no BOM (or ascii) with out carriage returns (\r) being inserted before every new line (\n) even when the incoming string didn’t have them. File encoding is just ONE of the reasons I hate PowerShell and why it’s so obviously clear people who were not qualified to design a shell, designed a shell. [1] https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_character_encoding?view=powershell-7.4 https://learn.microsoft.com/en-us/powershell/module/microsof... [2] https://stackoverflow.com/questions/5596982/using-powershell-to-write-a-file-in-utf-8-without-the-bom https://stackoverflow.com/questions/5596982/using-powershell...
yamapikarya 2y ago
i love windows terminal + git bash combo
WalterBright 2y ago
I constantly switch back and forth between Windows and Linux and it's always "dir" mixed up with "ls" coming from my fingertips. Grump grump grump Edit: I know I can use aliases and .bat files and whatever to make one look like the other, sort of, but then I learn some patchwork system and will be unable to use any other computer's login.
- SPBS 2y ago
  I almost never used `dir` because `ls` is supported by PowerShell. Is there a reason you have to use CMD?
  - WalterBright 2y ago
    Mainly because it isn't the default.
- mixmastamyk 2y ago
  I’ve made the dir and cls aliases on Unix for as long as I can remember. And keep dotfiles in git. Yes, computers out of your control won’t have them, but better to have them 90% (for me 99%) of the time rather than 50%—which is just annoying.
  - WalterBright 2y ago
    cp and copy, and \ and /, etc. My sanity is preserved, however, by having the same editor on all the machines I use. Although I can't get copy/paste to work in a remote text putty window. Sigh.
    - mixmastamyk 2y ago
      Yes, many windows things accept /, as I’m sure you know. Have used the ssh command instead, easy install now but twenty years ago had to hunt for openssl/ssh for windows. Console/Winterm should allow paste, though console puts on wrong mouse button of course.
doctorpangloss 2y ago
Busybox for Windows is much better. - Paths look much better: C:/Users/doctorpangloss == /Users/doctorpangloss == C:\Users\doctorpangloss. - The coreutils are just there. - Works flawlessly as an SSH or Dockerfile shell. - Fast and tiny. So small you can check it into git. - The maintainer is very responsive and fixes bugs quickly, even in upstream. git-bash has problems because of paths, terminal weirdness, and it doesn’t use native Windows APIs for a variety of things where it should. /c/ this, /mnt/ that. It’s not really possible to write multi platform scripts with it. With Busybox for Windows you can.
- alok-g 2y ago
  Awesome! I did mot know about this. Thanks.
esalman 2y ago
Git SDK for Windows is even more awesome, complete with a package manager for fetching more common unix tools with ease.
dundarious 2y ago
git bash's main benefit being that it's a commonly installed variant of the wonderful msys2 system, then yes, I tend to agree. Another wonderful benefit of git bash, is that because it is so commonly installed, if you want scripting for a dev/build tool, you can 99% of the time just use bash for your scripts, on linux and windows. I use this all the time for my build scripts. build/x86_64-linux-gnu-gcc.sh, build/x86_64-windows-msvc-cl.sh, etc. (These are generally simple single command line unity builds, parameterized only by debug, opt, etc.) Then from pwsh I can run these scripts with `& "$env:GIT_INSTALL_ROOT\bin\bash.exe" .\build\x86_64-windows-msvc-cl.sh`, similarly from cmd.exe. (Looks like a ton of typing, but it's not, I always Ctrl-R search and get a hit by just typing "git_"). No need to write a bat script, or even a pwsh one, pretty much ever again. Even if all you want is logic to cd to the script directory, parse a single script argument, check it's valid, provide a default, make some directories if not present, etc., bash beats all the alternatives on many fronts.
ruthmarx 2y ago
I've been pretty happy with clink [0]. I'm not looking to have the same environment everywhere, I'm fine to have windows stuff optimized for windows on windows, and vice versa on Linux. By that reasoning, I think clink is a much better option. [0] https://github.com/chrisant996/clink https://github.com/chrisant996/clink
- shortlived 2y ago
  Clink + windows terminal + Git tools is the perfect setup IMO.
aurelien 2y ago
You should try ArchLinux or Gentoo if you really want a shell as you desire ;)
konfekt 2y ago
For those without admin rights preferring ZSH to Bash in the Windows Terminal: install MSYS2 with scoop.sh, then the ZSH package with `pacman -S zsh` and add a shell with commandline `%USERPROFILE%\\scoop\\apps\\msys2\\current\\msys2_shell.cmd -defterm -here -no-start -ucrt64 -shell zsh` to launch it in Windows Terminal.
Hackbraten 2y ago
For me, the biggest downsides to Git Bash are: 1. I don’t understand how it relates to msys2 and where the boundary is, so I’m always reluctant to apply msys2 practices (documentation, advice, blog posts, etc.) to Git Bash. 2. I’ve been unable to figure out how to package scripts and other software for Git Bash so other users can install them.
- dundarious 2y ago
  For 2, just tell them to run %GIT_INSTALL_ROOT%\bin\bash.exe yourscript.sh, or you could provide a shim doing exactly that, and install that somewhere in their Path.
daghamm 2y ago
WSL inside the new Microsoft Terminal is my preferred Windows Shell.
bricss 2y ago
Git Bash + Windows Terminal = one luv
- grepfru_it 2y ago
  Git bash breaks password entry on certain tools that hides character input.
kennethrc 2y ago
I'm "All Linux, all the time" at home, develop in it, help out with the Kernel a little bit, only use Windows at home in a VM, etc. I'd just started working for a client that is fully entrenched in Windows, but we're doing bare-metal and Linux-y work. When I'd discovered I couldn't use Linux as my daily driver due to security/policy(/tooling) reasons, one of my co-workers told me about Git Bash, and it's worked out so well that ... <looks left, looks right> ... when we were given the opportunity to use Linux but VM Windows, I kept the Windows machine. GitBash has made Windows painless for my work's use-case. I should probably throw a few $$ at them ....
- jmkni 2y ago
  Can't you use WSL?
  - kennethrc 2y ago
    I have it available, but GitBash seems to work better with my workflow. BTW, when I checked to see how to donate, apparently my client pays for it; I thought it was OOS.
4oo4 2y ago
Git Bash is really nice for when I want a unix utility that will do the job simpler and better than Powershell, however it's painfully slow for larger I/O operations. I end up barely using it on my Windows 11 work machine because I'm allowed to have Linux VMs. Even with the VM overhead, and having fewer CPU cores and less RAM than the host, things still end up being way faster there. I remember one time running a grep command on a large-ish (~ 1 GB) log file in Git Bash and waiting at least 5 minutes for it to complete. After getting impatient I did the same thing in a VM and it took about 30-45 seconds, at which point Git Bash still had not finished.
- steve1977 2y ago
  Did you use endpoint protection in both systems? In my experience, that is often a factor of performance issue on the Windows side (and an unfair comparison when it is not used on Linux)

229 points by indigodaddy 2y ago

Its biggest advantage is how easy it is to convince corporate IT that you need Git for Windows, compared to msys2, Cygwin, or WSL.

xeromal 2y ago
So Say We All!
mid-kid 2y ago
This, corporate has been insisting on using ThreatLocker to block almost everything from running - Git For Windows is the only comfortable environment remaining, at least until I can convince them that this is stupid.
jfdjkfdhjds 2y ago
gitshell is a opinionated msys2 install. they just picked one of the variants and removed the package manager. this could serve as a wake up call to msys2 maintainers. every time i install it, i have absolutely no f ideia what the 6 variant icons mean and I couldn't care less since all of them mostly work... (thankfully I don't use windows much to reach a point the difference matters?) it's very overdue they just pick one and keep the others with better names in a compatibility folder or something. also, a better name.
- sevensor 2y ago
  If you’re not sure, you probably want UCRT64. At any rate I used it to pull a rabbit out of a hat at work by building some software with it that didn’t have an official windows build.
  - chrsw 2y ago
    Building in the URCRT64 environment means the executables wont run on versions of Windows older than 10 without extra runtime support, I think. So that's something to watch out for.
deleted 2y ago
[deleted]

NelsonMinar 2y ago

git bash is very cool. It's based on good ol' MSYS2 and MinGW which has always been a nice way to do minimalist Unix-like stuff in Windows. WSL2 is great these days and can interact fine with Windows files (despite what this article says). But it's a lot more stuff, a full Linux install in a VM.

exac 2y ago
I just had an IDEA nx plugin crash my editor until it was removed because it can't handle WSL directories, so I would not say it can interact fine.
- okl 2y ago
  Tip: Install the IDE inside WSL2. Should also run somewhat faster, especially any operation which has to do with many small files, at the expense of a tiny bit of latency in the GUI.
gchamonlive 2y ago
> a full Linux install in a VM Really? I always thought the subsystem worked translating OS calls back and forth without virtualizing an entire machine. It sure has an entire OS, kernel and all, but not a virtualization layer. Maybe that was the case for WSL but not WSL2?
- akdev1l 2y ago
  That was WSL1 and as a result had a bunch of unimplemented syscalls. Microsoft realized trying to keep up with the ever-growing list of syscalls on Linux is actually not practical hence they opted for the virtualized approach with an actual Linux kernel to achieve 1:1 syscall compatibility. They released that as WSL2. Technically the name is not accurate anymore as there aren’t any “subsystems” at work anymore.
- deleted 2y ago
  [deleted]
- jborean93 2y ago

bena 2y ago

It's weird, I mostly associate git bash with VS Code because it's the terminal I use most often with it. It doesn't occur to me to use it outside of that context. I use the command shell or Powershell depending on what I need to do.

delta_p_delta_x 2y ago

> I like Git Bash because… > I’m more comfortable with bash commands than CMD or PowerShell commands (because I’ve been using Bourne shell (sh) and friends for more than 30 years). This is the only argument I'm willing to accept, and honestly it's the only argument the writer needs, really: un-learning 30 years of experience to use something else even if the latter is objectively superior, would be a pain in the neck for anyone. That being said I believe that seriously attempting to use the native tools would help the author understand Windows at a more fundamental level. Also, this does raise a few questions, though—if the writer has been using UNIX shells for that long, why are they using Windows at all? As I commented elsewhere, why shoehorn the whole set of UNIX core utilities and binary utilities onto Windows when the latter comes with its own shell, command-line utilities, and management tools? More importantly, the author going by the rest of their posts (assuming it was the same author) doesn't strike me as the type (i.e. normie, for lack of a better word) to use Windows as a daily driver, but they seem to use it all the same. Therefore, why not an OS where these utilities feel more native and more useful, like Linux or one of the BSDs? In contrast to the author I've been using and programming almost nothing but Windows (with a brief stint on Linux in university and now at work, but only for work), and on Windows I use PowerShell and if I really need to, CMD.exe (good riddance). As far as compilation goes, I use Visual Studio with MSVC and Clang-Cl, because they are the only complete development environment for Windows—all the others (MinGW, Cygwin, MSYS2) are incomplete or worse in some way, or make life harder than necessary in some way. > I have experience using Windows PowerShell (powershell.exe), but do not yet have experience using the cross- platform PowerShell Core (pwsh). For the record, functionality between powershell.exe and pwsh.exe is almost identical, with some minor differences[1]. Additionally they differ in the .NET runtime they were written against (.NET Framework 4.8 for powershell.exe, and .NET 7 and later for pwsh.exe). [1]: https://learn.microsoft.com/en-gb/powershell/scripting/whats-new/differences-from-windows-powershell?view=powershell-7.4 https://learn.microsoft.com/en-gb/powershell/scripting/whats...

jaaron 2y ago
> why are they using Windows at all? In my case: - I had 10+ years of experience in linux/unix development - Career change to AAA game development which is predominantly Windows based - Day to day do Unreal C++ developing in Windows with Windows toolchains - Still use WSL (and thus bash) for everything else, including DevOps related work, cloud/container development work, and personal notetaking/productivity via emacs+org-mode. So, some of us have reasons to co-exist in multiple OS's. I tend to write up scripts in Python if I can so that there's at least a chance that I can run them in both Windows + Unix environments.

AdeptusAquinas 2y ago

Huh, didn't know it was basically bash commands for windows - I thought it was a faked up linux environment. I mostly just use ubuntu under wsl2, though the file performance across the windows filesystem isn't the best.

veltas 2y ago

mintty is a great TTY emulator for Windows

amatecha 2y ago

Oh yeah, I've been using Git Bash for years, it's great. It's nice being able to use a set of basic cli utils I'm used to (gnu utils) which are bundled in (not sure if it's 100% exhaustive in that regard, but still enough for me to do everything familiar). And yes, agree with and have benefited from every single bullet point TFA mentions!

indigodaddy 2y ago
mobaxterm has the basic cli tools as well perhaps even more so than git bash. For example it additionally has rsync and I think mc too

pauliusj 2y ago

Coming from mac to windows, a big surprise was how ridiculously slow printf is on any of the ms terminals (cmd, powershell, windows terminal). Git bash does not have this problem when you are running something pretty verbose yet want to view the output in the terminal

mid-kid 2y ago

My favourite shell environment for windows thus far is combining Git For Windows with scoop[1]. A simple "scoop install git" will get the environment installed, and give you a bash shell and full access to all sorts of windows-native utilities from scoop. Some would say I'd be better off with msys2 or cygwin, but the former is meant more as a development environment and lacks misc utilities, and the latter has what is possibly the worst package manager that is still in use (and generally less stellar integration with windows programs). [1]: https://scoop.sh/ https://scoop.sh/

wilsonnb3 2y ago
Any reason to choose scoop over chocolatey, which has been around forever, or winget which is included in windows these days?
- speilberg0 2y ago
  scoop generally installs to your local data, so most programs don't require admin access.
- beart 2y ago
  Scoop favors portable installs and typically manages upgrades and migrations for you. It does support non portable tools but these live in a different bucket. Chocolatey, and to a greater extent, winget typically defer to the individual applications. In my experience they are more like glorified download indexes than actual repositories for managing software.
- amenhotep 2y ago
  When I tried using chocolatey, you had to pay them in order to specify a default install directory rather than needing to include it explicitly in every command. I don't know if this is still the case but I formed a deeply held grudge over it. When I tried using winget, it mostly worked quite well, but occasionally would fail horribly. It'll happily detect and offer to upgrade programs that were installed outside winget, for example - great feature!! - except one time when I tried doing this it installed a new instance to a default location instead of upgrading in place, so now I had two installations. I don't trust it. Scoop is simple and sensible and just works in exactly the way I expect it to. With the exception of needing to install scoop-search.

dietr1ch 2y ago

Same, but NixOS is my preferred Windows too.

lynguist 2y ago

In this article I learned that _start_ is the equivalent of _open_ (from Mac). I didn’t know _start_ before.

righthand 2y ago

Honestly there are so many differences and little things on Windows that make using any of the CLIs not worth it. You will run up against gotchas developing on native Windows cmd, Powershell, git bash, and WSL. I left for Linux a long time ago and never have had to look back at the utter mess that is Windows. People stay on that platform for what? A graphical menu in the corner? Compatibility you don’t actually need? Use a real shell and OS and save your sanity.

johnea 2y ago

Why not just ditch the "windows" part entirely, and work on an OS that's not designed for the purpose of exploiting you as a user?

philipwhiuk 2y ago
Speaking personally, it's because the company only supports Windows for everything else.
gruturo 2y ago
For a lot of people, this is your employer's choice and not yours unfortunately. I jokingly remark that most of my contacts with microsoft products are non consensual.

cafard 2y ago

I was just using Git Bash to run grep...

Tempest1981 2y ago
And ripgrep

JackMorgan 2y ago

As a long time personal and professional Linux user, lately my work has led me to work for companies that are Windows-only. I use git bash as my main shell on Windows. It just works for what I need, and in the rare cases I need powershell I just open that. Most of the windows-based programmers I interact with don't know powershell any better than I do. They use GUI tools for interacting with git and the filesystem. So for me, git bash for git and filesystem interaction is a superpower in these places. I could learn powershell, and I'm pretty sure it's much better than bash for scripting, but I'm almost never really scripting in bash anyway, I use tools like F# for that. Powershell seems fine, but it's less well supported on Linux and I don't really need a shell based language. So in the end, git bash keeps on working and I can focus my learning elsewhere. It's stable, still works the same way 15+ years later, so no need to change.

oldsecondhand 2y ago
Another thing to consider is availability: many companies don't even allow powershell for dev users.
bena 2y ago
Powershell lets you install extensions and run commands against the clr. It’s basically a clr repl. If you need to interact with windows/microsoft specific things (i.e. Active Directory), it’s pretty convenient
deleted 2y ago
[deleted]

nikau 2y ago

Gitbash is handy for simple things, but it's a slug compared to wsl2.

niobe 2y ago

Well I took a different route. Always beem 'forced' to use Windows as my workstation by a couple of specialty apps without Linux alternatives that need direct hardware access. But have always used linux on everything else (servers, even my media centre). Because I'm sometimes a late adopter of new tech, until recently I used cygwin as my normal command prompt. There were few downsides to that if you just need access to unix tools, except package management is a bit annoying. Well, discovered the MS Terminal and WSL this year, and happily moved off cygwin. More recently decided to switch over from WS1 to WSL2 but still evaluating the move. Now I have a unix "more native" environment AND a linux distro I'm familiar with. I've been accessing the Windows filesystem under /mnt for two decades so this is normal for me, and if filesystem access is slower, it's not a dealbreaker. All my existing scripts were trivial to update. The integration of WSL and VSCode is also pretty cool. It means my vs code environment environment is also working natively in my WSL distro. Overall can understand some lingering negativity about MS efforts in this dept but after years of rejecting all things linux and open source, in general the 180 from the top is much appreciated and it has kept me on Windows a while longer...so mission accomplished microsoft. Just gotta do something about those pesky apps I still need...

rr808 2y ago

The reason I used to use Git Bash was to ssh to Unix boxes. Since Windows Terminal came out I dont use any more, Windows Terminal is much better.

Ayesh 2y ago
The post is about the shell; Windows terminal is only... Well ... A terminal.
- jborean93 2y ago
  And ssh is a binary so isn’t fully shell related :)
fud101 2y ago
its good but it has that bug with tmux that can be very frustrating.

locusofself 2y ago

I started using Linux in 1997. I've been working at Microsoft for a little over 4 years. There are some annoying things about Powershell (verbosity and slow loading of tab completions etc), but in some ways it's vastly superior to bash, as it deals with structured data and not just strings you have to parse, and it has an extremely powerful standard library API (.NET) at your fingertips. I still love bash and use it as well. But the hate powershell often gets is misguided.

irunmyownemail 2y ago
Bash rocks because it is about the user and the OS. Powershell is about one thing, Microsoft and the ugliness of ItS CumBerSomE-SynTaX Du-Jour is proof.
- psd1 2y ago
  Bash is about the user? Are you serious? It's about what twenty people could sling together and make work on a Vax in the 80s in 4Kb. Powershell has regular syntax, legibility, a high degree of discoverability, and included batteries for things that bash victims reimplement again and again. It may not be the best shell for your purposes - it certainly won't run in 4Kb - but it wipes the floor with all legacy shells for usability. You're welcome to have an aesthetic opinion on the syntax, but you must be dead inside if you can look at an average bash script and not recoil in horror. Argument parsing? sed? Control statements? Quoting and escaping? "It's all about the user" is it fuck, you're on drugs.
lnxg33k1 2y ago
I feel it's nice to have the power of choice, I can deal with structured data in bash as much as I need, whenever I need, with awk, but it isn't there when I don't
airtonix 2y ago
[dead]
skinner927 2y ago
There was a time in Powershell’s life when stdout redirection to a file (>) would write UTF-16, then that changed to UTF-8 with BOM and now it’s UTF-8 no BOM. During those times some PS versions would allow to change this globally, some would not. Even if you could change it globally, the names for the same encodings have changed. PowerShell 5.1 “UTF8” actually meant “UTF-8 with BOM” PowerShell 7 “UTF8” meant no BOM. If you read a file in PowerShell that does not have a BOM it decodes it as ANSI. Yes, ANSI, not Ascii. Which is a hilarious choice because you can’t even write an ANSI file in PowerShell. The closest encoding you can use is “Default” which will use the system default but your systems default might not be ANSI. PowerShell is a hot mess. Go read the official docs for character encoding[1] if you don’t believe me. I have CI scripts that have to use .NET calls[2] in PowerShell to write ssh keys to disk because it’s impossible to write utf-8 no BOM (or ascii) with out carriage returns (\r) being inserted before every new line (\n) even when the incoming string didn’t have them. File encoding is just ONE of the reasons I hate PowerShell and why it’s so obviously clear people who were not qualified to design a shell, designed a shell. [1] https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_character_encoding?view=powershell-7.4 https://learn.microsoft.com/en-us/powershell/module/microsof... [2] https://stackoverflow.com/questions/5596982/using-powershell-to-write-a-file-in-utf-8-without-the-bom https://stackoverflow.com/questions/5596982/using-powershell...

yamapikarya 2y ago

i love windows terminal + git bash combo

WalterBright 2y ago

I constantly switch back and forth between Windows and Linux and it's always "dir" mixed up with "ls" coming from my fingertips. Grump grump grump Edit: I know I can use aliases and .bat files and whatever to make one look like the other, sort of, but then I learn some patchwork system and will be unable to use any other computer's login.

SPBS 2y ago
I almost never used `dir` because `ls` is supported by PowerShell. Is there a reason you have to use CMD?
- WalterBright 2y ago
  Mainly because it isn't the default.
mixmastamyk 2y ago
I’ve made the dir and cls aliases on Unix for as long as I can remember. And keep dotfiles in git. Yes, computers out of your control won’t have them, but better to have them 90% (for me 99%) of the time rather than 50%—which is just annoying.
- WalterBright 2y ago
  cp and copy, and \ and /, etc. My sanity is preserved, however, by having the same editor on all the machines I use. Although I can't get copy/paste to work in a remote text putty window. Sigh.
  - mixmastamyk 2y ago
    Yes, many windows things accept /, as I’m sure you know. Have used the ssh command instead, easy install now but twenty years ago had to hunt for openssl/ssh for windows. Console/Winterm should allow paste, though console puts on wrong mouse button of course.

doctorpangloss 2y ago

Busybox for Windows is much better. - Paths look much better: C:/Users/doctorpangloss == /Users/doctorpangloss == C:\Users\doctorpangloss. - The coreutils are just there. - Works flawlessly as an SSH or Dockerfile shell. - Fast and tiny. So small you can check it into git. - The maintainer is very responsive and fixes bugs quickly, even in upstream. git-bash has problems because of paths, terminal weirdness, and it doesn’t use native Windows APIs for a variety of things where it should. /c/ this, /mnt/ that. It’s not really possible to write multi platform scripts with it. With Busybox for Windows you can.

alok-g 2y ago
Awesome! I did mot know about this. Thanks.

esalman 2y ago

Git SDK for Windows is even more awesome, complete with a package manager for fetching more common unix tools with ease.

dundarious 2y ago

git bash's main benefit being that it's a commonly installed variant of the wonderful msys2 system, then yes, I tend to agree. Another wonderful benefit of git bash, is that because it is so commonly installed, if you want scripting for a dev/build tool, you can 99% of the time just use bash for your scripts, on linux and windows. I use this all the time for my build scripts. build/x86_64-linux-gnu-gcc.sh, build/x86_64-windows-msvc-cl.sh, etc. (These are generally simple single command line unity builds, parameterized only by debug, opt, etc.) Then from pwsh I can run these scripts with `& "$env:GIT_INSTALL_ROOT\bin\bash.exe" .\build\x86_64-windows-msvc-cl.sh`, similarly from cmd.exe. (Looks like a ton of typing, but it's not, I always Ctrl-R search and get a hit by just typing "git_"). No need to write a bat script, or even a pwsh one, pretty much ever again. Even if all you want is logic to cd to the script directory, parse a single script argument, check it's valid, provide a default, make some directories if not present, etc., bash beats all the alternatives on many fronts.

ruthmarx 2y ago

I've been pretty happy with clink [0]. I'm not looking to have the same environment everywhere, I'm fine to have windows stuff optimized for windows on windows, and vice versa on Linux. By that reasoning, I think clink is a much better option. [0] https://github.com/chrisant996/clink https://github.com/chrisant996/clink

shortlived 2y ago
Clink + windows terminal + Git tools is the perfect setup IMO.

aurelien 2y ago

You should try ArchLinux or Gentoo if you really want a shell as you desire ;)

konfekt 2y ago

For those without admin rights preferring ZSH to Bash in the Windows Terminal: install MSYS2 with scoop.sh, then the ZSH package with `pacman -S zsh` and add a shell with commandline `%USERPROFILE%\\scoop\\apps\\msys2\\current\\msys2_shell.cmd -defterm -here -no-start -ucrt64 -shell zsh` to launch it in Windows Terminal.

Hackbraten 2y ago

For me, the biggest downsides to Git Bash are: 1. I don’t understand how it relates to msys2 and where the boundary is, so I’m always reluctant to apply msys2 practices (documentation, advice, blog posts, etc.) to Git Bash. 2. I’ve been unable to figure out how to package scripts and other software for Git Bash so other users can install them.

dundarious 2y ago
For 2, just tell them to run %GIT_INSTALL_ROOT%\bin\bash.exe yourscript.sh, or you could provide a shim doing exactly that, and install that somewhere in their Path.

daghamm 2y ago

WSL inside the new Microsoft Terminal is my preferred Windows Shell.

bricss 2y ago

Git Bash + Windows Terminal = one luv

grepfru_it 2y ago
Git bash breaks password entry on certain tools that hides character input.

kennethrc 2y ago

I'm "All Linux, all the time" at home, develop in it, help out with the Kernel a little bit, only use Windows at home in a VM, etc. I'd just started working for a client that is fully entrenched in Windows, but we're doing bare-metal and Linux-y work. When I'd discovered I couldn't use Linux as my daily driver due to security/policy(/tooling) reasons, one of my co-workers told me about Git Bash, and it's worked out so well that ... <looks left, looks right> ... when we were given the opportunity to use Linux but VM Windows, I kept the Windows machine. GitBash has made Windows painless for my work's use-case. I should probably throw a few $$ at them ....

jmkni 2y ago
Can't you use WSL?
- kennethrc 2y ago
  I have it available, but GitBash seems to work better with my workflow. BTW, when I checked to see how to donate, apparently my client pays for it; I thought it was OOS.

4oo4 2y ago

Git Bash is really nice for when I want a unix utility that will do the job simpler and better than Powershell, however it's painfully slow for larger I/O operations. I end up barely using it on my Windows 11 work machine because I'm allowed to have Linux VMs. Even with the VM overhead, and having fewer CPU cores and less RAM than the host, things still end up being way faster there. I remember one time running a grep command on a large-ish (~ 1 GB) log file in Git Bash and waiting at least 5 minutes for it to complete. After getting impatient I did the same thing in a VM and it took about 30-45 seconds, at which point Git Bash still had not finished.

steve1977 2y ago
Did you use endpoint protection in both systems? In my experience, that is often a factor of performance issue on the Windows side (and an unfair comparison when it is not used on Linux)