Hacker News Reader

> 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.

Fair point. I've edited my comment to show my impression that the author uses Windows as a daily driver, rather than merely 'for work', which I think makes the cause for my confusion a little clearer.

> 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.

Powershell is cross platform too these days, which makes this kind of a moot point.

Powershell had potential, but it didn't pan out. It's annoying and very challenging to remember all the one-off flags.

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.

I just wrote a two line bash script to process some large csv files that Python/Pandas were taking far too long to process [0].

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.

This is the opposite of how I see it. There's really nothing universal about flags, especially short ones, in different random utilities (what's -n mean? -f? file, filter or force?). Whereas in Powershell since there actually is some standardization, your knowledge about what -WhatIf or -Verbose do is actually pretty leverageable. And more powerful with the ability set default parameters and so forth. And the discoverability and help in Powershell is also standardized.

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 Windows is great because there’s a module for everything. I’d rather parse structured data.

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.

For what it's worth, I've had the opposite experience, maybe because I work in a different domain. Personally, I still think using Powershell functions and treating lines as string objects is an improvement over bash and its mini-languages, anyway; and most standard Unix commands have Powershell close equivalents. Some Powershell expressions might be abstruse but so is, say, awk; but when you've learned awk you only know awk; whereas the Powershell technique you used (calculated fields in select-object, for example) is permanently useful. I do spend a lot of my time with various random APIs so Powershell is pretty joyful compared to (say) curl/jq or yq-ish stuff. There was a real adjustment period, of course, getting used to a new shell; but it was the best thing about my experiment with Windows (discovering a new shell that I now use on my Unix-like systems, because I did not end up wanting to adopt Windows).

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.

Powershell's CSV, XML and JSON handing is my favourite Powershell feature. Completely agree with you that it beats a *nix shell and things like jq. If I was interacting with those all day I might be convinced to use it more.

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.

Thanks, that makes a lot of sense. I can see a lot of similar cases especially for sysadmin things (systemctl, ifconfig, etc.).

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

Like, there's no problem running that in powershell. I know people have talked about "mixing" strings and objects but, I have to say that for me I've rarely run into a problem with it?

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

And for me, the nice thing is that when you learn something like that, it's leverageable across all your cases. You learned something about your tool, not just about the passwd file.

Is this better than bash? I don't think it's worse:

  getent passwd | %{ ($_ -split ':')[5] } | group

But then you might notice that your data is a CSV (C for colon in this case) and you might leverage some of the CSV-handling which works well in Powershell:

  getent passwd | convertfrom-csv -del ':' -h 'user','pwd','uid','gid','comment','home','shell' | group -prop 'shell'

Now you're cooking with structured data again. I think familiarity makes this kind of thing come naturally. And since these commands are pretty discoverable, because they're more consistent, and tab-completion and command-line editing are so much better than bash. It's easy to see how the above can be made terser by stashing it into utility function or a hashtable in your profile (e.g. so you could do "getent passwd | fields passwd" or something like that.

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.

You learn all of that, find yourself logged into somebody else’s server, and you only have bash again.

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.

Oh, it's not dismissive at all. It's not just a real consideration, it's an overriding one. I switched my "daily driver" shell to powershell but I still write CI/CD scripts in bash, and docker entrypoints, and cloud-init userdata, and utilities, because it's niche enough to be too much to ask my coworkers and community folks to also switch.

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.

Bash is bloated. I have seen bash executables in the megabytes range. Preinstalled bash is not an argument in favour of using it.

Extracted, this Linux build of Powershell (v7.4.5) 174MB.

Yeah, it's hard to do a direct comparison, because bash needs a bunch of other utilities to be useful and they also take up space. In theory you can pick and choose but woe be to you if you want to use bash without sed, awk, cut, etc.

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.

> Powershell on Linux isn’t worth is because I end up having to parse everything as text anyway

Does it at least integrate with DBus a bit?

> Powershell on Windows is great because there’s a module for everything. I’d rather parse structured data.

It’s also really slow for text processing, borderline unusable

Bash + coreutils/busybox/etc are everywhere, I can take them for granted. I will have to jump through hoops to deploy Powershell outside of Windows.

I also have no desire to use Powershell when I don't need to.

But they aren’t on windows, so they can’t be taken for granted there. You have to install git bash on windows.

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.

I can run an MSYS2 installer on a Windows VM once and be done with it. I will have to roll my own containers, for example, if I want to use Powershell elsewhere, versus just using vanilla or vendor-provided images.

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.

I totally get that your solution works for you and that is fantastic. I’m only questioning the pure logic behind it when you strip away opinion/preferences.

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.

>> What’s the difference between installing git bash on windows and installing powershell on Mac/Linux? I would argue that there is none.

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?

Just because you aren’t familiar with Windows commands doesn’t mean they don’t exist.

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.

Git bash has a terminal emulation problem. It’s fixable, but annoying problem that breaks tools. I recommend Cygwin or more recently WSL.

YMMV

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.

This is a very succinct dissection of the problems but I will add one more: PowerShell's frustrating behavior where any return value of a function call is part of the enclosing function's return value if not explicitly swallowed. I understand what they were going for by analogy with other shells here, but in my opinion in a language like PowerShell (with actual return values) this is unintuitive and makes it really easy to introduce bugs. The whole object pipeline thing they were going for feels like an evolutionary dead end that we shouldn't be saddled with.

I agree, this is a place where the desired features are in tension. I will say that it took me a while to find it, and I don't find it limiting now that I understand it, but it was a real gotcha when I encountered it.

I'm not sure I understand your point regarding having to look at the output of commands to know how to use them. At least with Powershell you have tab-completion suggesting your object members; you have to at least look at whatever flavor of semi-parsable text is coming from your command in bash to use cut or awk or whatever on it (and the semantics of what you're looking at are not discoverable, so you're likely to have to some API digging of your own). 'cut' and the like is sadly fragile for a number of reasons, and you generally won't discover them in advance (e.g. when the date "field" starts containing a year, sizes overflow or start being indicated with human-readable abbreviations after a threshold, which is exactly the sort of thing you can't tell by inspection). And bash's failure modes are really sharp.

To be honest, something like

  $titled = gci *.md| ?{ (gc $_)[0] -like '# *' }

seems short and less error-prone than the bash equivalent. Not sure what it would be. Something like

  titled=(); for file in *.md; do if head -1 "${file}" | grep -sq '^# .*'; then titled+=("${file}"); fi; done

I think there's a lot of little gotchas in there, and not a little "API digging" for options, though it's simple in concept.

> you have to at least look at whatever flavor of semi-parsable text is coming from your command in bash to use cut or awk or whatever on it

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.

Your "diving through object hierarchy" has a _consistent_ command called "Get-Member". Not the same where you need to dive through several hundred text output structures for different commands and/or read man page options. I am sorry, but your statement is factually false.

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.

> 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.

I feel similarly - I first learned about the shell with Linux and all my career has been with Linux, but at home I use Windows. I am making an effort to be better at PowerShell but if I just want to do something quickly, I already know how to do it with bash and I just want to get on with my day.

> if the writer has been using UNIX shells for that long, why are they using Windows at all?

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.

At this point, this should be the industry standard. "Local" should be whatever you can SSH into. You can get as much hardware as you need, and you don't have to worry about anything private (i.e., customer information) and/or proprietary being on your lost / stolen laptop.

Perhaps the company is otherwise all in on Microsoft's ecosystem. Perhaps they use Outlook, Word, Excel and similar apps where the Linux version doesn't exist and the Mac version is an afterthought. So IT forces everyone to have a Windows system, and then give only the developers a separate Linux machine.

> 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.

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.

That was poor wording on my part—I should have used the subjunctive mood and written '… if the latter were objectively superior …'.

Not just poor wording but I think you misunderstood the authors context too. Some of his comments were comparing git bash to other POSIX layers like WSL, rather than Bash vs PowerShell.

> I think you misunderstood the authors context too

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.

> > I think you misunderstood the authors context too

> 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 think you're misunderstanding my comment.

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.

> I said the cornerstone argument for their blog was 'they were familiar with Bash

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.

> I literally just said he wasn’t just comparing Git Bash with Powershell though

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.

I appreciate what you’re saying but the author literally named the software they were comparing. WSL was specifically mentioned, by name, in some examples.

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)

In principal I agree with you but if there is one commonly used technology that is actually objectively inferior to the myriad of replacement options and is only still around because its been ubiquitous for decades, its bash.

“Inferior” and “superior” are broad terms.

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.

As a thought experiment, Get-ChildItem is a poor choice of API. Instead, it should really just be Get<T> <args>

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.

What is better than Bash shell? What I like most about it: It exists on every single Linux box that I use, so I can always run my Bash-specific shell scripts.

> if the writer has been using UNIX shells for that long, why are they using Windows at all?

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 make a living writing software that's hosted on Windows. I've never felt as comfortable with the command line options on Windows as I do with macos/Linux. Git bash with vim was such a relief.

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).

In my experience, it really does come down to the ergonomics: the cursor, the casing, the forward slashes, whatever key combo is required to paste (shift+insert?).

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.

PowerShell should be taught in university as example of how poorly designed system devoid of taste and aesthetic looks like. It's an ugly monstrosity that makes me puke every time I try to use it. The only reason some people might like it is because they have been tortured by Windows defaults for many years and finally they got used to this utter mediocracy.

It'd be good if you could actually justify why you think PowerShell is inferior to UNIX shells, instead of going on an impassioned but unsubstantiated rant.

I think powershell is actually really well designed. Some of the syntax leaves a bit to be desired, but other than that I think it's really good. What do you think is poorly designed?

> Some of the syntax leaves a bit to be desired

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.

Nothing like that, It's Mostly its fine, and certainly no worse than bash.

> why are they using Windows at all?

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.

The minor differences can be a major issue. Powershell 7 still doesn't come installed on any windows system as far as I know, so you are better off targeting Powershell 5, and unable to take advantage of the features offered by 7.

I find this interesting because, well, I’ve used bash on Windows for _ages_ (literally before the EMWACs toolkit came out for NT 4.0, and I spent many, many years running Cygwin).

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…

"shoehorn"

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.

WSL also adds yet another restart loop to the already lengthy process of turning a fresh machine into a workable Windows development station.

My take here - when working with stable system, changing OS once a several years (last one was when changing laptops basically, so 4+ years in my case), I don't care much on _single_ reboots. For those who tirelessly do distrohopping, things may look different of course.

Years ago, I had a teammate that was always pushing me to try Cygwin. While I love a UNIX shell, Cygwin just felt... weird. The whole paths thing really turned me off. What pushed me to try it? He said to me: Why bother learning two shells (UNIX + DOS), when you can just use one (UNIX) everywhere? I couldn't find a good argument against it. I tried Cygwin, and, eventually (never?) got over the weirdness of paths.

what about https://github.com/microsoft/terminal

you use that too right? you better!

Without question. I was so glad when 22H2 allowed users to change the default console host to Terminal; it was the single biggest reason why I decided to stay on Windows 10.

“When in Rome, do as the Romans do.”

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.

> 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.”

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.

Hah… I just realised that all of the pieces are now there for a “Windows” distro that uses the Linux kernel instead of the NT kernel.

> “When in Rome, do as the Romans do.”

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.

>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.”

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.

>if the writer has been using UNIX shells for that long, why are they using MSWindows at all?

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

>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?

An answer that I haven't seen offered yet: because Microsoft spend billions trying to gain and retain developer marketshare