Hacker News Reader

Comment by shortrounddev2 | Hacker News Reader

Powershell solves these problems by having structured data and types and not just streams of bytes

This isn’t related to pipes. This is related to how command lines and variables are tokenised and expanded. Zsh doesn’t have this issue, nor does most, if not all, other shells written in the last 10+ years.

It's related to pipes in the sense that if you write a pipe like `gci | % { foo $_.Name }` or `gci | % Name | bar` you won't have to worry about quoting either, because the `.Name` is a single string object and is not word split. But overall, yes the fundamental reason is that PS also does not do word-splitting on string values.

It’s not related to pipes. I’ve written a shell that has typed pipes and variables handle whitespace correctly. Those two are distinctly separate concerns. It just so happens that many modern shells solve both those problems but it doesn’t mean they’re related.

I recommend reading the comment you respond to before you respond to it.

The problem is both Windows and POSIX passes parameters as a string. So unless you’re never planning on interfacing with any external executables, you still need to convert that variable to a string. That’s where the concern is, not whether pipes are typed.

> because the `.Name` is a single string object

File path names are bytestrings on most OSes, so you have undefined behaviour if your pipeline can't handle that.

That's irrelevant to the overall point regarding word-splitting. dotnet represents filenames as String, so there can be nothing in the pipeline that couldn't handle them. Files whose names can't be represented in String are a dotnet problem, not a PS problem.

I am pretty sure that if something can't be handled by a program because it's underlying language can't handle it still counts as "program can't handle the problem".

"just don't mangle my filenames" is a pretty basic requirement for a universal use shell.

>> Powershell solves these problems by having structured data and types and not just streams of bytes

Powershell's structured data can cause issues if you expect it to be similar to Unix-like shells.

For example, Powershell mangles piped binary data by default:

https://brianreiter.org/2010/01/29/powershells-object-pipeli...

Correct handling of piped binary data requires additional flags:

https://stackoverflow.com/questions/54086430/how-to-pipe-bin...

Isn't this exactly what the parent was saying? "Stream of bytes" is not a meaningful thing that Powershell deals with by default. Using an operation like "pipe to file" on a text stream (like the Success output stream) will treat the stream as text, regardless of whether you managed to get raw binary data into the stream. This is kind of the whole point of Powershell: there is no such thing as raw binary data, and you have to work harder if you want to deal with something as bytes. It's certainly a culture shock coming from "everything is a stream of bytes" Unix-land.

>> This is kind of the whole point of Powershell: there is no such thing as raw binary data, and you have to work harder if you want to deal with something as bytes. It's certainly a culture shock coming from "everything is a stream of bytes" Unix-land.

Exactly. It means that system administrators need to be aware of the differences when working with Powershell versus other shells to avoid silent corruption of binary data.

Yes, and? A Python developer needs to learn a different language if they become a java developer. A sysadmin needs to learn Windows if they're going to administer Windows.

>> A sysadmin needs to learn Windows if they're going to administer Windows.

Powershell is cross-platform and runs on Linux and MacOS as well as Windows:

https://github.com/PowerShell/PowerShell

You can discover differences between Powershell and traditional shells as a Linux admin.

Ok, similarly, you'll need to learn powershell if your going to use it as a tool as a system admin

> if you expect it to be similar to Unix-like shells

And Python can cause issues if you expect it to be similar to Java. They're 2 different tools, so if you expect it to behave similarly to bash, that's on you

Not if java tried to call itself javashell, but didn't act like a shell.

Uh, why are sh and derivatives the final word on how a shell must behave? Or at least it appears that you are saying PowerShell doesn't "act like a shell".

Is this a No True Scotsman?

Why bother have words that mean things then? Call anything you want anything you want. Sounds useful.

Since when did the definition of a shell include "deals with everything as a unstructured stream of bytes"?

Agreed but at what cost?

Get-Process | Out-Host -Paging | Format-List

Case sensitive hyphenated compound word commands?

At the cost of having to press tab to auto-complete a statement you've written 10 billion times before. God forbid a software engineer has to type something

> Case sensitive

they're not

Also your command is equivalent to:

ps | oh -paging | fl

They're not case-sensitive.

Well I'm sensitive!

I don’t think it’s actually case sensitive. And there is autocomplete anyways.

Powershell is rather famously case insensitive.

It is idiomatic to capitalize liberally though.

Idiomatic in scripts (and documentation and training). REPL idioms are much more loosey-goosey.

That's actually something I have come to appreciate about Powershell is that idiomatic distinction concept that scripts are more likely to be read by other people (including Future You with no memory of having written the script in the first place) and to write "full sentences" for an audience, but feel free to be fast and loose in the REPL all you want.

Totally agree! I am a bash fanboi with a fish fetish, but recently started in a windows shop. I've actually grown quite fond of the flexibility powershell offers, and how usable it is without requiring esoteric knowledge.

Reply on news.ycombinator.com