Git Bash is my preferred Windows shell
ii.com
ii.com
I still love bash and use it as well. But the hate powershell often gets is misguided.
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.
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...
Windows Powershell is up until 5.1 because it runs ONLY on Windows.
Powershell 6 was named Powershell Core due to being built with .NET Core. It was not fully compatible with 5.1 and lacked some functions based on the WinApi.
PowerShell 7 is still built on .NET Core, but has a much better compatibility with 5.1. They dropped Core because nobody cared and it's shorter and works equally well on all platforms.
So Powershell is the v7 and Windows Powershell is the old 5.1. Nowhere is that confusing.
not actually "embedded", more like a bit of shim code that extracts the runtime into some temporary directory that then runs the actual code.
I can't speak for Jeffrey and his team, but I feel like a lot of their decisions came from trying to get corporate behind the shell and present it as a shell for Windows. They avoided picking political battles outside of their main goals (a modern shell to replace cmd.exe and the object-based pipeline model). What we've got are a set of decisions that aligned with Windows and Microsoft practices of that day and age:
Microsoft is focusing on .Net as their general platform? We'll implement PowerShell on .Net.
Windows's standard for Unicode text files is either UTF-16 LE or having a BOM for any other Unicode transformation? We'll do UTF-16 by default and always add a BOM if you choose UTF-8.
Windows is using CRLF? Well, we'd pipe CRLF-delimtied text by default.
Visual Basic and C# programmers expect functions to have names like "GetChildItem" instead of something like "dir" or "ls"? No problem, we will set the canonical command name to be a long, programming-language-like name and set up aliases that look (but don't behave) like Unix and cmd.exe commands.
The result was not pretty, but I still appreciate the ideas we got from PowerShell. nushell took these ideas and implemented them in a more modern way.
[1] https://corecursive.com/building-powershell-with-jeffrey-sno...
It doesn't seem like it could be for backwards compatibility, as now an old script that writes a file with defaults can't later read it with defaults?
Things have improved since then now that everything is implemented in .NET (Core), so if you're working with PoSH 7.x, this is no longer a headache. (I just tested in 5.1, and it seems fixed now, as well.)
Of course, by now, I've just developed muscle memory to add '-enc UTF8' to the end of everything that writes text to disk.
Edit: yup, just did small cmd line client and all works. Thanks.
I find that unfair towards their creators. They invented a truly innovational shell, whereas everybody else continued the text-based approach. The object-oriented approach is so much simpler when it comes to process results of Get-ChildItem (ls) or Get-Process (ps) when you get objects with properties, instead of just text. Especially when in text-based shells it matters how you call e.g., ps (aux or -efH or whatever).
Now, I find your statement unfair, because in Linux world, you just create a new shell and whoever wants to use it, can.
At Microsoft, a successor to cmd.exe had to be shipped with Microsoft, otherwise it would never have been adopted. Most big companies would never allow a third-party open-source shell on their Windows servers. Therefore, you must navigate a big ocean of politics and powers, guarantee nackwards-compatibility and meet expectations of thousands of companies. This inevitably leads to behaviour like encoding that is frustrating to use. Until you read the docs, which state quite comprehensively what you have to expect - as you discovered yourself.
As a comparison (to most of us semi-knowledgeable windows / powershell users), ask any semi-knowledgeable Linux user about the difference between Ksh/Bash (or that weird one that Ubuntu pushed and aliased to one of the above for extra confusion). Or ask them if any of them remember how tf to use SED or AWK without looking up the docs because those damn things are made by satan in the depths of hell. Or how to use parameters inside shell scripts, and the various incantations they have to slice and dice the params.
I've written in a lot of different languages in my time and never had this issue with anything else. It's weird.
people who rip on powershell but prefer bash make no sense to me at all
They're used to it, that's all. Just like how people used to US Customary find SI units weird and confusing.
e.g. Get-ChildItem is aliased to "gci", "ls", and probably "dir" as well.
You can do what ever you want for innovation but if you choose mindf*ck as your UI..
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 just think coming from a Linux background, it's very hard to wrap my mind around the mindset of PowerShell which is just quite different from Bash.
If you had to write something a little more complicated, I would consider F# in many ways than Powershell especially if I wanted the .NET tools.
Of course, there is python.
> 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...
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.
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.
Powershell is cross platform too these days, which makes this kind of a moot point.
With bash, you only need to learn 10 or 20 short commands and a few flag variants, over a gently long period of time. Then you're all set for 97% of cases likely to be encountered.
A lot of people (myself included) tend to underestimate the power of the heavily optimized GNU utilities and the ability to manipulate them with bash.
[0] It was two lines for readability. It could have easily been a single line.
So I get why unfamiliarity would make it not worth it to switch from whatever shell you prefer, but I don't think I can see your point about flags.
Powershell on Linux isn’t worth is because I end up having to parse everything as text anyway, completely negating any benefit I can come up with. It doesn’t feel as natural as the *nix tools to me.
So I'm curious what kinds of things you mean when you say you have to parse everything as text anyway. I suspect you've needed to a lot more of those kinds of tasks than I have.
What I mean by parsing as text was more about actual commands.
I wasn't expecting 1:1, but as an example, let's say I wanted to get a list of local users on a machine.
On Windows I can use "Get-LocalUser". It returns an object with properties you can filter, output with a format, etc. Basic stuff that saves me doing any thinking. I like that. It's amazing how column titles add to the user friendliness.
On Linux, Get-LocalUser doesn't exist, so I could run something like "getent passwd". It's only option is to return a screen of text. There's no structure yet, just lines and colons. Now I can (even though I shouldn't) grab fields with cut, or awk, and filter with grep, and maybe output something pretty at the end with column. What does the 5th column mean again?
So on the Linux side, I've never been very motivated to use it, since I often have to fall back to old ways anyway.
One thing that was nice about my adopting Powershell as my daily shell is that for the most part, I could just use the same shell utilities as usual:
getent passwd | cut -f6 -d':' | sort | uniq -c
As you learn you can do a little more. Maybe you learn that group (group-object) can be used instead of the two commands at the end:
getent passwd | cut -f6 -d':' | group
Is this better than bash? I don't think it's worse:
getent passwd | %{ ($_ -split ':')[5] } | group
getent passwd | convertfrom-csv -del ':' -h 'user','pwd','uid','gid','comment','home','shell' | group -prop 'shell'
Now, I'm not going to tell someone it's worth the growing pains and adjustments to switch. It's like switching keyboard layouts. And matters of taste might turn you off, understandable. But for me there have been real benefits, and on its merits, I do think it makes a better shell. And it would be nice (from my perspective) if the community did some more work around these use cases and making them nicer for people.
Sorry, trying to be funny, not dismissive.
I think shells in general could use some rethinking, considering they still feel pretty 80s.
Familiarity (or my lack of) is likely a big reason I’ll miss the obvious.
Zsh fills in many of the same checkboxes while being similar enough you don’t lose muscle memory when you find a bash shell somewhere.
Maybe someday something else will take over. Windows has the advantage there, for sure.
I do wonder about the muscle memory thing. I think having to create scripts in bash keeps my hand in enough that I won't lose it too badly. At least I hope so. I compared switching shells to switching keyboard layouts; something I also did, and something where it's been some effort to retain enough muscle memory to not completely flail when presented with another computer.
But it's true that, like, you get help with Powershell but that might not matter on a system where you wouldn't choose to install man pages or something.
Does it at least integrate with DBus a bit?
It’s also really slow for text processing, borderline unusable
I also have no desire to use Powershell when I don't need to.
What’s the difference between installing git bash on windows and installing powershell on Mac/Linux? I would argue that there is none.
And obviously it’s fine that you don’t want to use PowerShell, I don’t want to use it either. But personally I also dislike git bash on windows. It doesn’t feel like it belongs there, just like powershell doesn’t really belong on Linux/Mac.
If I had to write a build script for all three platforms I would just write them for their native environments. I wouldn’t be all that willing to add another tool to be installed just to save myself the effort of simple build script.
For my use case, I don't see the need to bend my builds around Powershell just to use Powershell. This plays into my other point about not wanting to dig into Windows fundamentals when I don't need to.
> If I had to write a build script for all three platforms I would just write them for their native environments. I wouldn’t be all that willing to add another tool to be installed just to save myself the effort of simple build script.
This was my initial approach, but it became too much work to maintain separate build systems, especially when it came to making changes over time. One change becomes three, along with three new opportunities for things to break in three separate ways.
For what I'm doing, moving to Unix-y toolchains simplified builds and made it much easier to reason about it.
You picking one OS that you’re okay with modifying but the other one you’re not. If we inversed that preference and said that I’m willing to modify my Linux containers but unwilling to install software on my Windows VM, the logic is the same.
By the way, Microsoft publishes Linux images that already have PowerShell pre-installed.
https://learn.microsoft.com/en-us/powershell/scripting/insta...
So, technically, if your build scripts were 100% PowerShell you could have it where both Windows VMs and Linux docker images could be unmodified.
Since your build scripts sound overly complex, they could possibly benefit from a scripting language that’s got support for objects and object data pipelines, more advanced error handling, and more advanced object parsing than tools like sed and awk.
Just playing “devil’s advocate” here, the logic checks out.
Big, big difference. My Windows laptop is basically a terminal to the Linux development server. I can install anything (within reason) on Windows, can't install shit on the Linux server unless I beg the IT admin for days and eventually he just says "no". He did install the "mc" (Midnight Commander) utility on it though and made my life like 100x easier. If MC were bundled with git bash, that would be something I would cheer for.
And yeah, I use git bash too on Windows. For accessing the Linux shell through ssh when I remotely connect to the server and for convenience locally. Main workhorse are the "less" and "grep" utilities to examine logs. What am I goint to use otherwise, Notepad?
Microsoft actually gives you SSH without the need to install git bash.
https://learn.microsoft.com/en-us/windows/terminal/tutorials...
grep on windows is Select-String
https://learn.microsoft.com/en-us/powershell/module/microsof...
More command on windows:
https://learn.microsoft.com/en-us/windows-server/administrat...
What will you use to view logs, Notepad? Well, you could use the #1 most popular text editor that Microsoft happens to develop, VSCode. Or a wide array of Windows GUI software that isn’t available on Linux, like Notepad++.
The fact that your IT department has those specific policies in place and is inflexible with your developers isn’t really relevant to this discussion. The truth is that if you wanted PowerShell on Linux it is trivial to install. Microsoft even publishes Linux images that already include PowerShell.
YMMV
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.
you use that too right? you better!
I have to use PowerShell, but since it essentially wraps .NET services I very much prefer to either write C# (and have vastly more maintainable and testable code) or, when removing, invoke the APIs using a Unix scripting language. And these days I can write nice “portable” (ok, retargetable) binaries inside WSL and output a Windows build if I need to…
Desktop applications would probably be the usual reason. It's all well and good if your application needs are covered by open source, but there's a fair bit of software with value add beyond open source that's never received a Linux version and WINE doesn't support well enough.
Of course, as you say, then you have the problem of the shortcomings of various *nix environments for Windows. MacOS can be a great solution... if your app still runs under MacOS (currently I'm trying to figure out how to get Fireworks to run under a minimal windows or mojave VM).
I don’t respect the attitude of doing whatever you’ve always done, even when working in a wildly different environment.
Imagine how Linux people would react if there were endless blog posts about using VB6 scripts on Linux by running them under WINE because “that’s what feels familiar.”
Sure, for a lark that’s hilarious, but not if you share your work with anyone else for any reason, even open source.
Heh, that would be hilarious. In fact someone should come up with a Linux distribution that uses NTFS, PowerShell, comes with .NET, WINE, and no coreutils and blog about it.
Parent is obviously choosing the "Veni Vidi Vici" side of the coin. If they can pull it off, why not ? It's their machine after all.
Alternatively, we could ask why the POSIX-sphere produces enough power users impassioned to, interested in and capable of enabling their pet projects on a closed and hostile platform for blog posts like the OP's but the reverse does not.
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.
This I did not. The post was about Git Bash as a command-line shell for Windows and everything it entailed, I understood that and that's why I wrote the paragraph that followed.
I was limiting the scope of my comment to the author's familiarity on Bash versus CMD or PowerShell because I considered that the cornerstone argument of the entire post. Everything else that the author mentions is expected by default in a *sh-type shell on a Unix-like OS; there's nothing special there. People wouldn't blog about being able to use `grep`, `ls`, etc on Linux; it's just everyday business.
> This I did not. The post was about Git Bash as a command-line shell for Windows and everything it entailed, I understood that and that's why I wrote the paragraph that followed.
I literally just said he wasn’t just comparing Git Bash with Powershell though. So you can’t have understood their context if you took Powershell to be the “cornerstone”.
It’s a bit of a muddled blog because he is constantly switching focus between “Git Bash” (the package / distribution; whatever term you want to describe it as) and Bash.exe (the shell).
There are a lot of the comparisons are with things like WSL, for example when he discusses the underlying file system. And when he talks about the ease of installing and keeping things up to date. None of that was directed at Powershell specifically, nor even at all.
I said the cornerstone argument for their blog was 'they were familiar with Bash, so they don't use the shells that come with Windows', not 'they are comparing Bash with PowerShell'.
Given that everything else is detailing what about Git Bash is familiar, which as far as I am concerned is everyday business. The author discusses things like Unicode and the other GNU coreutils. Again, this is what you'd expect on a Unix-like.
That wasn’t the cornerstone either. That was just the only argument of theirs you chose to accept:
I quote:
> This is the only argument I'm willing to accept,
I do understand your point of view, I honestly do, but you’re not being charitable to the author nor genuine when discussing it with me.
That's great that you think that, maybe delta_p_delta_x had a different takeaway. Why do you believe your opinion about what the cornerstone of the article is to be fact?
> If there’s one thing I can’t stand in IT, it’s people who think their personal preferences (or opinions) are equivalent to impartial facts.
That’s not subjective opinion of mine because it’s literally printed like that on their site (you can read it for yourself too. It’s the same site for everyone)
Architecturally speaking, Powershell (and other modern shells) are a huge improvement. But that’s only half the story.
Syntax wise, I find powershell a step backwards. It’s too verbose. Bash is too far the other way but if I’m using a REPL then I’d rather have something too terse than too verbose. Granted that’s just my preference but we are back to subjective arguments.
Ubiquity is another consideration. If you’re writing multiplatform bootstrapping code then Bash is a better option than Powershell. And we are back to subjective arguments again.
Broad terms are only true if you can agree on a specific context. But then they’re no longer broad and instead you’re relying on everyone agreeing to that narrow subjective definition.
Get<Folder> -path "C:\Users\Me\My Documents"
Would return a match of type <Folder|nil>
similarly
Find<Folder> -path "C:\Users" -match "Me"
Would return a match of type <Folder[]|nil>
or
Find<Any> -path "C:\Users" -match "Me"
Would return a match of type <Any[]|nil> where Any is
File|Folder|DotFile|Symlink
In as few lines I provided a clean API which unfortunately doesn't exist in any one language but rather borrows from multiple languages, <T> representing C# generic types, File|Folder representing an F# union sum type, Any type a la Rust.
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.
To be honest, something like
$titled = gci *.md| ?{ (gc $_)[0] -like '# *' }
titled=(); for file in *.md; do if head -1 "${file}" | grep -sq '^# .*'; then titled+=("${file}"); fi; done
Having to parse things is definitely a pain, at least until you get good at it. But the critical thing is that all the output is right there on the screen, and often in a format that's at least somewhat designed to be parsed. In PowerShell you have to go diving through the object hierarchy. That would be OK I guess if things were intuitive and the help and documentation were great but that's often not the case. And often the API semantics are designed for a different language altogether (C#) and the things you have to do to consume the API in PowerShell are ugly.
The simplest technique for analyzing the objects that a command returns is to pipe the output of that command to the Get-Member cmdlet. The Get-Member cmdlet shows you the formal name of the object type and a complete listing of its members.
It's an idiosyncratic mix of ergonomics and habit probably. I don't really care since I get the job done efficiently (more so than a lot of "Windows natives" I observe).
I'm sure PowerShell and friends are great but it's enough of a shift to not be worth the learning curve if it's an environment you're just dipping into to do the bare minimum required to make something work.
MSwindows is posix, why not?
windows supports tons of software that is not available on unix. People have to work with other people, spouses, university colleagues, whoever, maybe those people use MSWindows
I'm a back-end developer/DevOps/Linux sysadmin who runs a small consultancy. I've been brought into a few Windows projects -- primarily on-prem/interactive installations. The past few occasions because the client was using Windows because the FE was being built using TouchDesigner. (Not sure it's still Windows-only but it was previously.)
So, it happens. Clients have many reasons for running Windows and depending on the project and its needs, I may accept the requirement or not. To use a recent couple of examples, if I can use GitBash, Docker, WSL and Python locally, then I'll probably take it on. If they're set on using PowerShell, C# and Azure, I'm probably out.
That all being said, if the project is interesting or high profile enough, I'll jump through whatever hoops are put in front of me.
That's quite poor design for a shell! It's like saying an OS is well designed except the mouse and keyboard input leaves a bit to be desired - because they were designed for scripting first and users second.
Git Bash is an elegant solution that brings some of the awesome Gnu utilities and does it on Windows terms and effortlessly. No shoehorn needed.
WSL is handy (those times I'm forced to use Windows - which is still better than when I'm forced to use Mac) but you have to remember the whole time you're in WSL, you're in Linux proper and all things work as Linux, generally, sort of. Git Bash is the power of Gnu right on Windows.
An answer that I haven't seen offered yet: because Microsoft spend billions trying to gain and retain developer marketshare
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.
- 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.
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.
It’s basically a clr repl.
If you need to interact with windows/microsoft specific things (i.e. Active Directory), it’s pretty convenient
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...
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 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.
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 ....
[1]: https://scoop.sh/
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.
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.
Installing something with scoop means downloading a declarative json manifest, with occasional, short pre-install/post-install levels of scripting (in all cases I've seen, it amounts to testing if a file is present, and copying it if so, etc.). The complexity that is tolerated for the scripting is much much lower.
I've also found chocolatey to be less well curated, with some odd packages with simple names that come from random people who don't seem to do a great job at maintaining the package.
scoop is preferable on every metric, IMO.
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.
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?
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.
[1] https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-pro... [2] https://devblogs.microsoft.com/commandline/announcing-wsl-2/
WSL1 was a completely different approach, adding a Linux compatibility layer to Windows itself. There, you never had a Linux kernel running at all-- Linux syscalls would call into WSL, which would talk directly to the NT kernel to do whatever that syscall needed to do.
WSL1 didn't last very long (still present, but not actively being developed)-- turns out that reimplementing one operating system on top of another is a Hard Problem (see also: Wine). WSL2 avoids this entirely, and also avoids most of the impedance mismatches that you get when trying to reimplement POSIX on top of NT. WSL2 solved a whole bunch of compatibility problems essentially overnight that WSL1 never even got around to.
is that true when using Docker with WSL2?
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.
Although I can't get copy/paste to work in a remote text putty window. Sigh.
I do know. But it isn't complete, whether it works or not depends on which command or program you're using. It's not really predictable.
Posix programs ported to Windows have similar problems - they often remain case sensitive with filenames.
At least all the programs I write work accept both \ and /, and are case sensitive on Posix and case insensitive on Windows.
Depends on stuff like what terminal Putty emulates and so on, of course, but... Eh, have you tried using the old "MS/IBM CUA standard shortcut keys, [Ctrl]-[Ins] and [Shift]-[Ins]? (And, for completeness' sake, [Shift]-[Del] for Cut.)
AIUI, those are Putty's standard keys for that. I've always assumed that's because, you know, a 'Nix command line would interpret [Ctrl]-[C] rather differently.
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.
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.
I mostly just use ubuntu under wsl2, though the file performance across the windows filesystem isn't the best.
I jokingly remark that most of my contacts with microsoft products are non consensual.