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.
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.
Nushell is plenty fast, works with structured data (also has a vi mode if you care, I do) and works equally well on Windows and Linux. You can install it with winget on windows and with cargo or the system's package manager on linux.
I am a C# developer so I should feel right at home with Powershell. In some ways I am. I do manage to get things done if I have to use it. If I am inside the Windows environment (with other Windows devs) I will try to encourage using it over CMD.
One thing I will give Powershell credit for is, back in 2012, being able to chuck something together when I did not have the development tools I needed. I knew that Powershell was .NET under the hood so I had a stab at being able to load my DLL files and calling methods inside a class. It did the trick! I was able to hand it over, suggesting they use it as a Task Scheduler (daily) and hardly anyone touched it during the remaining of that promotion (4 months)
Despite all this, if I ever have to write a script for odd execution or regular automation... I wish I could use bash. I have mentioned Git For Windows or using WSL but I just cannot win anyone over. Its not like anyone is an expert on shell scripting.. powershell or whatever.
As much as I like Powershell -- I still consider bash to be better. I think half of this reason boils down to what you are accustomed to. I have been using Linux properly since.. around.. 2006.
I've used powershell a bit, particularly for scripting CI pipeline steps. No matter how much I use it, I can never remember anything about the syntax. I primarily use C#, so you'd think there'd be some affinity, but nope. It's like a black hole.
I've written in a lot of different languages in my time and never had this issue with anything else. It's weird.
AIUI the verbosity is by design to make scripts more clear, and users are expected to use aliases to make cmdlets easier to work with interactively. But I assume that few of those aliases are actually standardized...
Powershell introducing the English language to a shell at a time when everyone else was doing i18n is about 3 leaps beyond an annoying thing in the traditional Microsoft form of the time.
You can do what ever you want for innovation but if you choose mindf*ck as your UI..
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
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.
> 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).
> 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?
I'm a Linux user and developer who writes software targeting Windows.
Tools like Git Bash and MSYS2 let me write one set of build scripts that work across Windows, macOS and Linux, because all of the tools exist on the three platforms.
I don't have a need to understand Windows on a more fundamental level, nor do I want to. I just want to meet my users where they are at, which is Windows/macOS/Linux.
I used bash in college and then didn’t use it for around 5 years. And then I used powershell.
And bash is still a lot better as a shell language. Powershell commands are long and annoying. If you remember all the aliases (most of which are annoyingly bash commands but hardly behave that way) then the parameters are long and annoying.
Stringing commands together requires too much API digging because objects mean you need to run a variety of incantations on the results to know what members you need to pull out and what data format they have, etc. in Bash it’s always strings and if you know a couple of useful string manipulation commands such as cut, that you probably know anyways for other reasons, you can get by with stringing most commands fairly trivially.
Powershell OTOH is a lot better when I’m trying to write an actual reusable script. But at that point why wouldn’t I just use something like Python anyways (or if it will be associated with a front end repo I will often just use nodejs since it’s definitely installed). Python has much more usable comparison, control flow, etc operators, much bigger libraries, better multi OS compatibility etc.
The only advantage really is using powershell commands/applications, so sometimes I will write my scripts in Powershell.
But in Linux I will also sometimes write my scripts in bash for the same reason, so it’s not really an advantage inherent to powershell, but the fact that it’s the “standard” of the OS.
I do like Powershell, but the problem with it is that it tried to be both a great scripting language and a great shell language, but the things that make it a good scripting language, such as verbose naming, objects, etc make it a worse shell language than shell languages designed to be shell languages first, and the things that it does to make it a useable shell language, makes it a worse scripting language than other scripting languages.
On average it may be the best language across all environments and use cases. The problem is that for any specific environment and use case it’s rarely one of the better languages.
- 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.
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.
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.
- 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.
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.
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...
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.
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 ....
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
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).
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.
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?
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.
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.
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.
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.
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.
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.
[+] [-] locusofself|1 year ago|reply
I still love bash and use it as well. But the hate powershell often gets is misguided.
[+] [-] skinner927|1 year ago|reply
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/microsof...
[2] https://stackoverflow.com/questions/5596982/using-powershell...
[+] [-] cassepipe|1 year ago|reply
https://www.nushell.sh/
[+] [-] masfoobar|1 year ago|reply
One thing I will give Powershell credit for is, back in 2012, being able to chuck something together when I did not have the development tools I needed. I knew that Powershell was .NET under the hood so I had a stab at being able to load my DLL files and calling methods inside a class. It did the trick! I was able to hand it over, suggesting they use it as a Task Scheduler (daily) and hardly anyone touched it during the remaining of that promotion (4 months)
Despite all this, if I ever have to write a script for odd execution or regular automation... I wish I could use bash. I have mentioned Git For Windows or using WSL but I just cannot win anyone over. Its not like anyone is an expert on shell scripting.. powershell or whatever.
As much as I like Powershell -- I still consider bash to be better. I think half of this reason boils down to what you are accustomed to. I have been using Linux properly since.. around.. 2006.
[+] [-] Yodel0914|1 year ago|reply
I've written in a lot of different languages in my time and never had this issue with anything else. It's weird.
[+] [-] dblohm7|1 year ago|reply
[+] [-] klingoff|1 year ago|reply
You can do what ever you want for innovation but if you choose mindf*ck as your UI..
[+] [-] devnullbrain|1 year ago|reply
[+] [-] airtonix|1 year ago|reply
[deleted]
[+] [-] lnxg33k1|1 year ago|reply
[+] [-] irunmyownemail|1 year ago|reply
[+] [-] delta_p_delta_x|1 year ago|reply
> 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...
[+] [-] heavyset_go|1 year ago|reply
I'm a Linux user and developer who writes software targeting Windows.
Tools like Git Bash and MSYS2 let me write one set of build scripts that work across Windows, macOS and Linux, because all of the tools exist on the three platforms.
I don't have a need to understand Windows on a more fundamental level, nor do I want to. I just want to meet my users where they are at, which is Windows/macOS/Linux.
[+] [-] addicted|1 year ago|reply
And bash is still a lot better as a shell language. Powershell commands are long and annoying. If you remember all the aliases (most of which are annoyingly bash commands but hardly behave that way) then the parameters are long and annoying.
Stringing commands together requires too much API digging because objects mean you need to run a variety of incantations on the results to know what members you need to pull out and what data format they have, etc. in Bash it’s always strings and if you know a couple of useful string manipulation commands such as cut, that you probably know anyways for other reasons, you can get by with stringing most commands fairly trivially.
Powershell OTOH is a lot better when I’m trying to write an actual reusable script. But at that point why wouldn’t I just use something like Python anyways (or if it will be associated with a front end repo I will often just use nodejs since it’s definitely installed). Python has much more usable comparison, control flow, etc operators, much bigger libraries, better multi OS compatibility etc.
The only advantage really is using powershell commands/applications, so sometimes I will write my scripts in Powershell.
But in Linux I will also sometimes write my scripts in bash for the same reason, so it’s not really an advantage inherent to powershell, but the fact that it’s the “standard” of the OS.
I do like Powershell, but the problem with it is that it tried to be both a great scripting language and a great shell language, but the things that make it a good scripting language, such as verbose naming, objects, etc make it a worse shell language than shell languages designed to be shell languages first, and the things that it does to make it a useable shell language, makes it a worse scripting language than other scripting languages.
On average it may be the best language across all environments and use cases. The problem is that for any specific environment and use case it’s rarely one of the better languages.
[+] [-] jaaron|1 year ago|reply
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.
[+] [-] scintill76|1 year ago|reply
Maybe the IT department policies force them to. At least that's why I use Windows but do most of my development in an ssh terminal to a Linux system.
[+] [-] hnlmorg|1 year ago|reply
It’s “subjectively superior”.
If there’s one thing I can’t stand in IT, it’s people who think their personal preferences are equivalent to impartial facts.
You disagreeing with the author’s reasoning is evidence of just how subjective this topic is.
[+] [-] sevensor|1 year ago|reply
[+] [-] jfdjkfdhjds|1 year ago|reply
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.
[+] [-] mid-kid|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] xeromal|1 year ago|reply
[+] [-] doctorpangloss|1 year ago|reply
- 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|1 year ago|reply
[+] [-] JackMorgan|1 year ago|reply
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.
[+] [-] niobe|1 year ago|reply
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...
[+] [-] dundarious|1 year ago|reply
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|1 year ago|reply
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
[+] [-] shortlived|1 year ago|reply
[+] [-] kennethrc|1 year ago|reply
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|1 year ago|reply
[+] [-] pauliusj|1 year ago|reply
[+] [-] mid-kid|1 year ago|reply
[1]: https://scoop.sh/
[+] [-] indigodaddy|1 year ago|reply
https://paste.almalinux.org/2A
[+] [-] wilsonnb3|1 year ago|reply
[+] [-] bena|1 year ago|reply
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.
[+] [-] NelsonMinar|1 year ago|reply
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|1 year ago|reply
[+] [-] wnevets|1 year ago|reply
is that true when using Docker with WSL2?
[+] [-] gchamonlive|1 year ago|reply
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?
[+] [-] WalterBright|1 year ago|reply
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|1 year ago|reply
[+] [-] mixmastamyk|1 year ago|reply
[+] [-] Hackbraten|1 year ago|reply
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|1 year ago|reply
[+] [-] 4oo4|1 year ago|reply
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.
[+] [-] AdeptusAquinas|1 year ago|reply
I mostly just use ubuntu under wsl2, though the file performance across the windows filesystem isn't the best.
[+] [-] konfekt|1 year ago|reply
[+] [-] yamapikarya|1 year ago|reply
[+] [-] daghamm|1 year ago|reply