Calling native binaries

[johan-boule]

Traditionally, the main purpose of a shell language has been to plumb native binaries together. I know that the spirit of powershell is to try to convert the whole world into cmdlets, but the reality of the world is such that we will continue to call native binaries.

So, i think a chapter dedicated to calling native binaries is needed.

One very important point that's not stressed enough in the book is that powershell lacks the equivalent of standard shell's "set -e": if you set $ErrorActionPreference to Stop, this will by no way make your life easier to deal with failing native binaries. IMHO this should be clearly stated as a warning in big bold red font because that's kind of a design issue, and clearly not at all the behavior that people have come to expect after a long exposure to standard shell.

Also, I think the behavior of calling a powershell "subscript" from powershell itself, e.g. ".\script.ps1" should be documented because, yet again, this is not working at all like standard shell where you don't have to care whether you're calling a real binary of a wrapper script since it always runs in another process. In contrast, powershell treats this specially and does not start any additional process when it's a powershell script.

[concentrateddon]

You're absolutely welcome to offer these changes in a pull request!

[johan-boule]

Well, I understand this point but you've got to realise two things that were perhaps not apparent enough in my comment: 1) The whole matter is such a mess that I, like many people, am absolutely unable to even think about how to document that. 2) As there are already other well tested and documented shells that don't exhibit such problems, I wonder why I should at all get involved into documenting something that's fundamentally broken. I'm not paid to clean someone else's obvious mistakes, especially when they come from the historic bad guys.

[concentrateddon]

So, just to make sure you're aware - this project is all-volunteer, as is our organization. We don't work for Microsoft. The ebook project was just an effort to help document "what is" for the community, not create a discussion around "what should be" (the PowerShell GitHub repo would be a good place to log issues against the code). I'm not trying to make you love PowerShell vs other shells, nor am I able to justify what PowerShell is and does. We've no actual control over what PowerShell is and does. I understand completely if you don't want to contribute to the project, but the only way this particular project grows is through volunteer contributions.

[johan-boule]

Fair enough, I didn't mean to make an association between contributors of a newly converted freesoftware and the original authors, but here you are now, and there are choices to make as to what ecosystem you're willing to invest your time in.