It works very well if you're all inside powershell.
Try this exercise: make a .BAT invoke a powershell script that invokes another .BAT passing parameters containing double quotes inside. It just can't be done reliably. The .BAT is only just an example, any param passing to/from powershell (outside powershells internals) is a nightmare.
In bash, this kind of interaction is commonplace. You can make `find` generate shell snippets for you, and pipe the generate shell commands into another interpreter instance seamlessly.
Think of the sheer amount of software the uses the shell this way and you never notice. That npm script that just passes parameters along is relying on the shell interface, that CI yaml that passes variables is relying on the the shell interface, etc. It runs just for a few milliseconds, to pass and glue things around, super simple. Powershell is just not designed nor suitable for that.
The problem of an uniform interface _can_ be solved by changing how people write stuff. The problem of not fitting well as an architectural piece replacement is much more difficult to overcome. Powershell fits Windows though, but that's about it.
Powershell passes data not instructions and a lot of those complaints sound like trying to write another language in Powershell.
I've shoved json from node through Powershell into the clipboard and back to filter with select-object and out.
the situation making you invoke bat at all is what MS ruined and that's not Powershell fault.
Technically it's Windows' "here's a string of the commandline, go parse it yourself" (vs. argv array) that's the issue as every program can interpret quoting, escaping etc. differently. All these programs being from MS (powershell, cmd) does make them a little guiltier I guess.
This is what I meant, these are all examples working around the default execution policy. That's microsoft ruining things not powershell as a language. I didn't say it was niche rare or wrong. It's just bad and it's MS's fault.
Try this exercise: make a .BAT invoke a powershell script that invokes another .BAT passing parameters containing double quotes inside. It just can't be done reliably. The .BAT is only just an example, any param passing to/from powershell (outside powershells internals) is a nightmare.
In bash, this kind of interaction is commonplace. You can make `find` generate shell snippets for you, and pipe the generate shell commands into another interpreter instance seamlessly.
Think of the sheer amount of software the uses the shell this way and you never notice. That npm script that just passes parameters along is relying on the shell interface, that CI yaml that passes variables is relying on the the shell interface, etc. It runs just for a few milliseconds, to pass and glue things around, super simple. Powershell is just not designed nor suitable for that.
The problem of an uniform interface _can_ be solved by changing how people write stuff. The problem of not fitting well as an architectural piece replacement is much more difficult to overcome. Powershell fits Windows though, but that's about it.