3 ms·
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,
by Arnavion 3y ago
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.
- ElectricalUnion 3y ago> 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.
- Arnavion 3y agoThat'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.
- ElectricalUnion 3y agoI 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.
- hnlmorg 3y agoIt’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.
- deleted 3y ago[deleted]
- Arnavion 3y agoI recommend reading the comment you respond to before you respond to it.
- hnlmorg 3y agoThe 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.