Hacker News Reader

Comment by fnovd | Hacker News Reader

Very cool, but even so it's hard to see the benefit of learning PowerShell just for Linux. Interacting with objects instead of text is definitely a huge plus. However, the main benefit of bash is the portability. If you have to set up a special scripting environment on every machine you're working with, you're better off setting up something with a "proper" language instead (as noted by the author). If I'm willing to give up the ability to dump my script in an unconfigured environment and have it work, PowerShell is nowhere near the top of my list.

If you spend most of your time in the Windows ecosystem, then there's no reason not to learn it. If I had cut my chops with PowerShell instead of bash I'm sure I'd be clamoring for some kind of LSW system. There's a reason why things went the other way, though. I don't think we're going to get Rust bindings for C, either.

View on HN

> However, the main benefit of bash is the portability

This was the reason why I learned PowerShell. It is the only shell that works on Windows/Linux/OS X (to those who don't know, it's open source now: https://github.com/PowerShell/PowerShell ).

Every team I join is a mix of Windows and Mac users with the occaisional Linux user. This is the only shell that you can use to across all three without compromise. Otherwise I find that whatever platform is dominant writes the helper scripts and the others get shrugs and "figure it out". Now, you could try to write them in Python, which isn't the worst idea, but it's not a shell.

Bash is available on all of those platforms, and has a hell of a lot more momentum.

It also has a hell of a lot more footguns.

> Now, you could try to write them in Python, which isn't the worst idea, but it's not a shell.

jupyter notebooks have filled this void for me, especially with vscode integration and ipywidgets. I want to learn and like powershell, but my junk drawer of automation helpers is too full to start from scratch.

U have Powershell notebooks https://github.com/dotnet/interactive

Is it installable using vanilla-esque yum or apt?

It's available as an Ubuntu snap. Not exactly what you are asking for...

It's intentionally different than UNIX shells. If you are expecting UNIX shell behavior you will not like it.

I have to use it at work for Windows stuff. It is amazing. But I would never install it on my home computer because I don't trust all the other Microsoft stuff that comes along with it.

There is one big complaint that I do have with it - working with massive (multiple gigabyte) files is a pain. It wants to load the entire file before doing anything; most likely because it wants to treat everything as an object - therefore it has to build the objects before it can work with them.

> I have to use it at work for Windows stuff. It is amazing. But I would never install it on my home computer because I don't trust all the other Microsoft stuff that comes along with it.

Can it finally manage Office 365 and the like from Linux?

I tried it once (1-2 years ago) to run some command that couldn't be done from the web interface. The docs said, "this should work". As I expected, it didn't. Some further digging turned up that it didn't support OAuth2 or something related to authentication.

It needs the Microsoft repository registered if it is not already. Then you can just do the usual apt commands.

> PowerShell. It is the only shell that works on Windows/Linux/OS X

What? POSIX sh

Windows does not have a native POSIX shell. Nor does it have most of the POSIX utilities that are necessary to make a raw POSIX shell script usable. So you have to install an entire suite of utilities to make Windows look like it is POSIX--there's a couple different such suites, each with their own quirks (especially as Windows' guts is pretty far from POSIX). And you still get to cringe because things like having to spawn a new process to compute a substring is expensive on Windows.

Well, and Linux (or MacOS) doesn't have PowerShell natively either, and PS has a smaller user base and it's more Windows-focused (just look at the naming conventions).

And you're going to want to install a newer version of Powershell on the Windows machines because most do not ship with a version (e.g. 7) comparable to the MacOS/Linux versions.

They do have native Powershell. It builds natively on those platforms whereas Bash on Windows requires shims.

For at least the past 7 years I've installed 'Git for Windows'[1] on every Windows PC I use. Git for Windows comes with bash (my primary shell on Windows) plus a full suite of *nix utilities including Perl, awk, sed, pdftotext, ssh and many more. This has sufficed as my primary scripting platform on Windows, with the intended benefit that my scripts are mostly portable to Linux.

[1] https://gitforwindows.org/

> However, the main benefit of bash is the portability

For me the main benefit of PowerShell is portability. I now just have one bootstrapping script for my cross-platform project, which works on Powershell Core on Windows, Powershell Core on Linux and if I wanted also Windows Powershell or MacOS.

This is the Debian POSIX shell:

  $ ll /bin/dash
  -rwxr-xr-x 1 root root 85368 Jan  5 09:52 /bin/dash

That shell can go places that Powershell will never, ever see, because Powershell is too big.

There really isn't any way that Powershell could change this.

> Interacting with objects instead of text is definitely a huge plus.

It's a huge minus. The fact that all shell tools produce text is a basic tenet of shell programming which underlies the composability and interoperability of them all.

> the main benefit of bash is the portability

No, see above. Also, you probably mean ubiquity rather than portability.

> If you spend most of your time in the Windows ecosystem, then there's no reason not to learn it.

The reason is that it will make you only work with other tools by Microsoft, or at best some Microsoft-centric companies which write such tools. Those tools might gain some benefit from working with non-textual objects, but the detriment in variety and composability (even ignoring multi-platform work) is massive.

Another detriment would be how it's non-shell-like work. Part of the idea of shell scripting is that it's work that you might have done "yourself", manually, manipulating the text. With something like PowerShell - you need a debugger, data viewers etc. In fact, one could argue that PowerShell is barely a shell.

> It's a huge minus. The fact that all shell tools produce text is a basic tenet of shell programming which underlies the composability and interoperability of them all.

PowerShell is essentially a cut down .NET environment with some nice syntax-sugar for typical shell activities. The objects in PowerShell are marshalled to/from text the same as in any other programming language.

So you can still write your tools as normal. Any PowerShell specific objects would just be a wrapper, or extra metadata. If we're being honest we already have that for other shells to make them more convenient: autocompletions. PowerShell objects give you autocompletions, type information, and interoperability with .NET libraries _but for data in addition to commands_.

The shell to programming language continuum has enough space to permit richer interpretations of the base data tools emit. We don't lose composability.

> With something like PowerShell - you need a debugger, data viewers etc.

Oh, what I would give for better shell script debugging. This is right up there with better CMake debugging for me.

Reply on news.ycombinator.com