4 ms·

Question for the PowerShell afficionados: Do you consider PowerShell to be "something we can count on to exist on Windows systems, in the absence of Bourne-like

Question for the PowerShell afficionados: Do you consider PowerShell to be "something we can count on to exist on Windows systems, in the absence of Bourne-like shells" - or is it "a superior alternative to Bourne shells which only got traction on Windows because Bourne is too deeply embedded in the Unix world"?

Arnavion 5y ago
... Neither? It's a superior alternative to cmd.exe. bash has never been a serious contender for Windows. Before PS you always wrote .bat scripts for cmd.exe (or .vbs for cscript.exe if you were really depraved). Nobody except Linux-first FOSS authors would expect Windows users to have cygwin / msys / mingw32 installed. PS gave us a saner choice, though we would still usually bundle it with a .bat wrapper, just to a) make it double-clickable and b) set `-ExecutionPolicy Unrestricted`. If you're asking "is PS better than bash", then sure it's better in some ways and worse in others, but that question only makes sense on Linux where bash is actually an option.
- einpoklum 5y ago
  But instead of coming up with PS, it would have been pretty straightforward to just install bash on Windows. Someone chose to go the PS way rather than the bash way. My question is what the reason was for making this choice. > Nobody except Linux-first FOSS authors Bourne shell and its predecessors and successors are traditional and common on most computer systems since the early 1970s (starting with the Thompson shell in 1971; see: https://en.wikipedia.org/wiki/Unix_shell https://en.wikipedia.org/wiki/Unix_shell ) so, I would argue actually the other way around. "Everybody except Windows-only closed-source authors would expect people to have bash or similar shell working." The question is, why go for PS instead of adopting a regular shell.
  - Arnavion 5y ago
    I'm really not sure what your point is. >Someone chose to go the PS way rather than the bash way. Are you asking about users or the Microsoft employees who work on Windows? Users don't want to install either bash or PS, which is why before PS existed all scripts were written for cmd.exe which was guaranteed to be available. Microsoft employees would have no benefit from adding bash to Windows given its license, and PS integrates better with the OS anyway. The author of PS is already on record that one of the original reasons was to integrate better with WMI etc [1]; given how hard / impossible it is to munge the output of ls etc in bash it should be no surprise than an object-based shell with saner expansion rules works better. >> Nobody except Linux-first FOSS authors >Bourne shell and its predecessors and successors are [...] You don't have to give me a history lesson. What you said has nothing to do with the fact that the only people who expected Windows users to have bash were Linux software authors, because their software only supported being built by bash scripts (and required make, configure, perl, what have you). Windows software itself, whether open or closed source, was built using cmd.exe scripts or VS project files. [1]: https://stackoverflow.com/a/573861/545475 https://stackoverflow.com/a/573861/545475
  - raverbashing 5y ago
    Let's be real honest here, bash sucks. "common on most computer systems since the early 1970s" yes, that's exactly the problem, it still thinks spaces on filenames are an "exception", just as a start. It knows about lines but barely. PS has native json support.
  - sidpatil 5y ago
    > most computer systems since the early 1970s How are you defining "most"? Back in those days there was much more diversity in the computing landscape.
  - jodrellblank 5y ago
    J. Snover started out bringing Unix (VMS) shell to Windows, and it isn't a good fit. Everything isn't text and so the Unix shell tools are pretty limited. So they made something which is a good fit for Windows everything-is-an-API instead. > "The question is, why go for PS instead of adopting a regular shell." The question is, why stick with 1970s stuff when you can have progress?
  - x0n 5y ago
    Simply because on Unix, configuration is text files; bash and the gnu utils work with text. In Windows, it's an API driven O/S; powershell uses objects, but will coerce output to strings to allow text parsing if needed.
sterlind 5y ago
the latter, though I may have some Stockholm syndrome. killer features: * objects are streamed, not text. I look upon sed and awk and their ilk as stone knives and bear skins. why not just dot into fields? * first-class interaction with libraries. I can import managed DLLs and call their methods. I don't have to build weird little one-off tools or expose porcelain. I can get at everything, it's profoundly hackable in an un-Windows way. * the language is vectorized - basically like broadcast operators in something like NumPy. $x.foo gives you x's foo if x is an object, or an array of foos if x is an array of objects. it's really really nice. * separate commands in one binary and argument (sets) are first-class. there's consistent rules about what "-i" will be short for. personally, I can pull all the valid commands and arguments automatically into my accessibility software for voice typing. the whole standard "verb-noun" thing also makes commands be what you expect and discoverable. things I don't like include the language itself, its weird bindings to .NET (it predated the C# dynamic support and modern collection types), the restriction to .NET, bad support for streams (not sequences), the slowness, and the syntax looks a bit goofy. but it's worth the warts.
- polotics 5y ago
  Cygwin has been a reliable features-complete alternative IMHO
  - sidpatil 5y ago
    How is Cygwin comparable? That's like saying Wine can be compared to cmd.exe.
    - polotics 5y ago
      Cygwin brings me a compatible-enough layer on top of windows that I can reuse scripts. It is comparable as it gives me a CLI, and to hen as it is not infected by Microsoftisms it gives me a warm feeling of safety..
- at_a_remove 5y ago
  I found -- when I last did anything in Powershell years ago -- that third point of yours to be incredibly frustrating. I wanted to iterate over a list, but sometimes I would get back a non-iterable solo object, or a None-like object, and my iteration would fail. I ended up doing a lot of testing to see what my returned results were.
oaiey 5y ago
Bash as a shell is not so outstanding. It is the gnu tools and the other command line first Landscape. So bash on windows can never fly because these tools are not natively present (cygwin and friends are just awkward). So Powershell (and the new terminal) gives us this whole package with its build-in, service and windows provided commandlets. Consequently: bash will never beat PS on Windows except when someone provided a gnu tools and hundreds of other command line tools for windows.
- oaiey 5y ago
  On the topic of Powershell on Linux I think the story there could be different, however Powershell violates the core philosophy of Linux so hard (mit vs. GPL, pipe-and-filter vs loaded DLLs, ...) that Powershell will never be something integral and natural fitting there.
  - deleted 5y ago
    [deleted]
  - sidpatil 5y ago
    > mit vs. GPL By this measure, we shouldn't be using X or Wayland because they're MIT. > pipe-and-filter vs loaded DLLs At first I didn't understand what you were referring to, but I realized you were talking about cmdlets. In that regard, PowerShell is more like a scripting language than it is like a traditional Unix shell. The more "Unix-like" approach would be to write thin command-line wrappers around the libraries you want to use. If I'm not mistaken, this is how projects like LAME and FFmpeg are implemented.
    - oaiey 5y ago
      Regards the licencing: you are right. I was a vit blinded by the core gnu tools. Tiny wrappers do not work since .NET, while being very Performanz will never be C like tiny.
      - sidpatil 5y ago
AndrewDucker 5y ago
Dealing with objects rather than strings and parameter autocompletion give massively better discoverability than other shells I've used. Being able to use all of the .Net classes trivially is also staggeringly useful.
jrsj 5y ago
(Not an aficionado) I feel like it is superior in many ways, but the syntax and case sensitivity have always been a barrier for me. It’s still worth it though when it’s the right tool. I don’t do Windows stuff often though so it’s always jarring coming back to it from bash.
- juki 5y ago
  > syntax and case sensitivity have always been a barrier for me Can you clarify that a little? PowerShell isn't case sensitive, and the syntax is just a mixture of traditional shell syntax (pipes, operators like -eq/-ne/-lt/-gt, etc.) and conventional C#-like syntax (if/elseif/else, switch, ?:, ??, try/catch/finally/throw, etc.).
  - jrsj 5y ago
    There’s some gotchas with case sensitivity that I honestly can’t remember but I think it was related to some of the more C#-y bits. As for syntax it really is the .NET elements & the relative verbosity of common things you’d interact with that just make it feel very foreign to me personally. This probably has more to do with Windows and .NET than PowerShell itself though.
lazypenguin 5y ago
Honestly I enjoy writing powershell more than bash scripts. Bash syntax is arcane and sometimes inconsistent where as powershell 7+ is fairly comfortable syntax. However, powershell does often feel cludgy and I often have have to figure out how to do more complex things. Not a perfect solution but it integrates with Windows nicely.
drblast 5y ago
It's a better design, imo. Have you ever wanted to write a command line executable and gotten hung up on I/o and parameter parsing? With PowerShell you can write a cmdlet in C# as a PowerShell module and have strongly typed input and output parameters for free. It's a revelation. As as scripting language, it's fine but for me the killer feature is being able to easily extend it in a non-scripting language.
bitwize 5y ago
PowerShell works on fundamentally different principles than do traditional Unix shells. Unix shells are for loosely coupling small "do one thing and do it well" programs. PowerShell can kinda do this, but its strengths lie in the "object streaming" features which aren't based on external processes at all but on loading .NET libraries with a special API, called cmdlets. In this respect PowerShell is a bit more like the VMS command processor, or using Python or Tcl as a shell. To add a command to a Unix shell, you need but drop an executable in your path. To add a command to PowerShell that takes advantage of PowerShell's features, you need to write a cmdlet in a language like C# and then install the cmdlet. This is also why PowerShell takes so long to boot up: it's probing for and loading installed cmdlets. For these reasons I do not consider PowerShell to be directly comparable to Unix shells, but it is an essential part of the Windows toolkit because no one wants to use the MS-DOS-like cmd.exe for anything serious.
rufius 5y ago
The latter. I say that as someone who only works with nix systems for the last 5 years. I still write some powershell for stuff at home. I prefer Hyper-V as a hypervisor and use it there. But the current state makes sense. Everything in Windows is COM, .NET, or a derivative thereof. Having a scripting language that natively speaks to these technologies in a flexible manner is a natural extension. nix is a lot more of the file based stuff and so a shell language that makes it easy to run a series of tools that operate on text is natural (I.e. awk, sed, grep, xargs)
justsomehnguy 5y ago
> in the absence of Bourne-like shells I never had "Oh I would really liked to have *sh on this Win machine". Some GNU tools, like grep (just because findstr has it's own arcaneties) or sed - but neither of them is the part the shell itself. Sure, before 2012 if you wanted a little more flow control than provided by cmd you had not really many options (and if you needed portability you would need to use VB/Jscript, not a 3rd party tool), but since then you have PS3 at worst (on 2012/R2), or at least PS5.1 everywhere else, including client SKUs. And writing even not a complex script with a bunch of if..else is way, way easier in PS, be it for a Win or a *nix machine.
majkinetor 5y ago
Its far superior, like light years superior. PowerShell will exist, entire MS ecosystem is now based on it. That fear has passed years ago, especially when it got cross-platform. I expect actually to see more pwsh on linux and even OTB pwsh linux distribution (heck, I will make it myself if needed when I get retired).
jodrellblank 5y ago
> "Do you consider PowerShell to be "something we can count on to exist on Windows systems" Once, yes; then they renamed it "Windows PowerShell" and deprecated it so it's no longer being developed. Instead they started trying to appeal to Linux users with new cross-platform "PowerShell" which you have to install separately. Windows PowerShell is increasingly falling behind that in performance and compatibility. We're heading away from "PowerShell included" back to the old world of "if you have to download and install something to get away from this abandonware legacy thing, why not Python or node.js?". > "a superior alternative to Bourne shells which only got traction on Windows because Bourne is too deeply embedded in the Unix world"?" It's a superior alternative to Bourne shells on Windows, and because it's basically Microsoft-Perl or Microsoft-Clunky-Python as well as being a shell, as in - it's more capable than Unix shell because it's a kitchen sink of scripting and programming language as well as command line.

Arnavion 5y ago

... Neither? It's a superior alternative to cmd.exe. bash has never been a serious contender for Windows. Before PS you always wrote .bat scripts for cmd.exe (or .vbs for cscript.exe if you were really depraved). Nobody except Linux-first FOSS authors would expect Windows users to have cygwin / msys / mingw32 installed. PS gave us a saner choice, though we would still usually bundle it with a .bat wrapper, just to a) make it double-clickable and b) set `-ExecutionPolicy Unrestricted`. If you're asking "is PS better than bash", then sure it's better in some ways and worse in others, but that question only makes sense on Linux where bash is actually an option.

einpoklum 5y ago
But instead of coming up with PS, it would have been pretty straightforward to just install bash on Windows. Someone chose to go the PS way rather than the bash way. My question is what the reason was for making this choice. > Nobody except Linux-first FOSS authors Bourne shell and its predecessors and successors are traditional and common on most computer systems since the early 1970s (starting with the Thompson shell in 1971; see: https://en.wikipedia.org/wiki/Unix_shell https://en.wikipedia.org/wiki/Unix_shell ) so, I would argue actually the other way around. "Everybody except Windows-only closed-source authors would expect people to have bash or similar shell working." The question is, why go for PS instead of adopting a regular shell.
- Arnavion 5y ago
  I'm really not sure what your point is. >Someone chose to go the PS way rather than the bash way. Are you asking about users or the Microsoft employees who work on Windows? Users don't want to install either bash or PS, which is why before PS existed all scripts were written for cmd.exe which was guaranteed to be available. Microsoft employees would have no benefit from adding bash to Windows given its license, and PS integrates better with the OS anyway. The author of PS is already on record that one of the original reasons was to integrate better with WMI etc [1]; given how hard / impossible it is to munge the output of ls etc in bash it should be no surprise than an object-based shell with saner expansion rules works better. >> Nobody except Linux-first FOSS authors >Bourne shell and its predecessors and successors are [...] You don't have to give me a history lesson. What you said has nothing to do with the fact that the only people who expected Windows users to have bash were Linux software authors, because their software only supported being built by bash scripts (and required make, configure, perl, what have you). Windows software itself, whether open or closed source, was built using cmd.exe scripts or VS project files. [1]: https://stackoverflow.com/a/573861/545475 https://stackoverflow.com/a/573861/545475
- raverbashing 5y ago
  Let's be real honest here, bash sucks. "common on most computer systems since the early 1970s" yes, that's exactly the problem, it still thinks spaces on filenames are an "exception", just as a start. It knows about lines but barely. PS has native json support.
- sidpatil 5y ago
  > most computer systems since the early 1970s How are you defining "most"? Back in those days there was much more diversity in the computing landscape.
- jodrellblank 5y ago
  J. Snover started out bringing Unix (VMS) shell to Windows, and it isn't a good fit. Everything isn't text and so the Unix shell tools are pretty limited. So they made something which is a good fit for Windows everything-is-an-API instead. > "The question is, why go for PS instead of adopting a regular shell." The question is, why stick with 1970s stuff when you can have progress?
- x0n 5y ago
  Simply because on Unix, configuration is text files; bash and the gnu utils work with text. In Windows, it's an API driven O/S; powershell uses objects, but will coerce output to strings to allow text parsing if needed.

sterlind 5y ago

the latter, though I may have some Stockholm syndrome. killer features: * objects are streamed, not text. I look upon sed and awk and their ilk as stone knives and bear skins. why not just dot into fields? * first-class interaction with libraries. I can import managed DLLs and call their methods. I don't have to build weird little one-off tools or expose porcelain. I can get at everything, it's profoundly hackable in an un-Windows way. * the language is vectorized - basically like broadcast operators in something like NumPy. $x.foo gives you x's foo if x is an object, or an array of foos if x is an array of objects. it's really really nice. * separate commands in one binary and argument (sets) are first-class. there's consistent rules about what "-i" will be short for. personally, I can pull all the valid commands and arguments automatically into my accessibility software for voice typing. the whole standard "verb-noun" thing also makes commands be what you expect and discoverable. things I don't like include the language itself, its weird bindings to .NET (it predated the C# dynamic support and modern collection types), the restriction to .NET, bad support for streams (not sequences), the slowness, and the syntax looks a bit goofy. but it's worth the warts.

polotics 5y ago
Cygwin has been a reliable features-complete alternative IMHO
- sidpatil 5y ago
  How is Cygwin comparable? That's like saying Wine can be compared to cmd.exe.
  - polotics 5y ago
    Cygwin brings me a compatible-enough layer on top of windows that I can reuse scripts. It is comparable as it gives me a CLI, and to hen as it is not infected by Microsoftisms it gives me a warm feeling of safety..
at_a_remove 5y ago
I found -- when I last did anything in Powershell years ago -- that third point of yours to be incredibly frustrating. I wanted to iterate over a list, but sometimes I would get back a non-iterable solo object, or a None-like object, and my iteration would fail. I ended up doing a lot of testing to see what my returned results were.

oaiey 5y ago

Bash as a shell is not so outstanding. It is the gnu tools and the other command line first Landscape. So bash on windows can never fly because these tools are not natively present (cygwin and friends are just awkward). So Powershell (and the new terminal) gives us this whole package with its build-in, service and windows provided commandlets. Consequently: bash will never beat PS on Windows except when someone provided a gnu tools and hundreds of other command line tools for windows.

oaiey 5y ago
On the topic of Powershell on Linux I think the story there could be different, however Powershell violates the core philosophy of Linux so hard (mit vs. GPL, pipe-and-filter vs loaded DLLs, ...) that Powershell will never be something integral and natural fitting there.
- deleted 5y ago
  [deleted]
- sidpatil 5y ago
  > mit vs. GPL By this measure, we shouldn't be using X or Wayland because they're MIT. > pipe-and-filter vs loaded DLLs At first I didn't understand what you were referring to, but I realized you were talking about cmdlets. In that regard, PowerShell is more like a scripting language than it is like a traditional Unix shell. The more "Unix-like" approach would be to write thin command-line wrappers around the libraries you want to use. If I'm not mistaken, this is how projects like LAME and FFmpeg are implemented.
  - oaiey 5y ago
    Regards the licencing: you are right. I was a vit blinded by the core gnu tools. Tiny wrappers do not work since .NET, while being very Performanz will never be C like tiny.
    - sidpatil 5y ago

AndrewDucker 5y ago

Dealing with objects rather than strings and parameter autocompletion give massively better discoverability than other shells I've used. Being able to use all of the .Net classes trivially is also staggeringly useful.

jrsj 5y ago

(Not an aficionado) I feel like it is superior in many ways, but the syntax and case sensitivity have always been a barrier for me. It’s still worth it though when it’s the right tool. I don’t do Windows stuff often though so it’s always jarring coming back to it from bash.

juki 5y ago
> syntax and case sensitivity have always been a barrier for me Can you clarify that a little? PowerShell isn't case sensitive, and the syntax is just a mixture of traditional shell syntax (pipes, operators like -eq/-ne/-lt/-gt, etc.) and conventional C#-like syntax (if/elseif/else, switch, ?:, ??, try/catch/finally/throw, etc.).
- jrsj 5y ago
  There’s some gotchas with case sensitivity that I honestly can’t remember but I think it was related to some of the more C#-y bits. As for syntax it really is the .NET elements & the relative verbosity of common things you’d interact with that just make it feel very foreign to me personally. This probably has more to do with Windows and .NET than PowerShell itself though.

lazypenguin 5y ago

Honestly I enjoy writing powershell more than bash scripts. Bash syntax is arcane and sometimes inconsistent where as powershell 7+ is fairly comfortable syntax. However, powershell does often feel cludgy and I often have have to figure out how to do more complex things. Not a perfect solution but it integrates with Windows nicely.

drblast 5y ago

It's a better design, imo. Have you ever wanted to write a command line executable and gotten hung up on I/o and parameter parsing? With PowerShell you can write a cmdlet in C# as a PowerShell module and have strongly typed input and output parameters for free. It's a revelation. As as scripting language, it's fine but for me the killer feature is being able to easily extend it in a non-scripting language.

bitwize 5y ago

PowerShell works on fundamentally different principles than do traditional Unix shells. Unix shells are for loosely coupling small "do one thing and do it well" programs. PowerShell can kinda do this, but its strengths lie in the "object streaming" features which aren't based on external processes at all but on loading .NET libraries with a special API, called cmdlets. In this respect PowerShell is a bit more like the VMS command processor, or using Python or Tcl as a shell. To add a command to a Unix shell, you need but drop an executable in your path. To add a command to PowerShell that takes advantage of PowerShell's features, you need to write a cmdlet in a language like C# and then install the cmdlet. This is also why PowerShell takes so long to boot up: it's probing for and loading installed cmdlets. For these reasons I do not consider PowerShell to be directly comparable to Unix shells, but it is an essential part of the Windows toolkit because no one wants to use the MS-DOS-like cmd.exe for anything serious.

rufius 5y ago

The latter. I say that as someone who only works with nix systems for the last 5 years. I still write some powershell for stuff at home. I prefer Hyper-V as a hypervisor and use it there. But the current state makes sense. Everything in Windows is COM, .NET, or a derivative thereof. Having a scripting language that natively speaks to these technologies in a flexible manner is a natural extension. nix is a lot more of the file based stuff and so a shell language that makes it easy to run a series of tools that operate on text is natural (I.e. awk, sed, grep, xargs)

justsomehnguy 5y ago

> in the absence of Bourne-like shells I never had "Oh I would really liked to have *sh on this Win machine". Some GNU tools, like grep (just because findstr has it's own arcaneties) or sed - but neither of them is the part the shell itself. Sure, before 2012 if you wanted a little more flow control than provided by cmd you had not really many options (and if you needed portability you would need to use VB/Jscript, not a 3rd party tool), but since then you have PS3 at worst (on 2012/R2), or at least PS5.1 everywhere else, including client SKUs. And writing even not a complex script with a bunch of if..else is way, way easier in PS, be it for a Win or a *nix machine.

majkinetor 5y ago

Its far superior, like light years superior. PowerShell will exist, entire MS ecosystem is now based on it. That fear has passed years ago, especially when it got cross-platform. I expect actually to see more pwsh on linux and even OTB pwsh linux distribution (heck, I will make it myself if needed when I get retired).

jodrellblank 5y ago

> "Do you consider PowerShell to be "something we can count on to exist on Windows systems" Once, yes; then they renamed it "Windows PowerShell" and deprecated it so it's no longer being developed. Instead they started trying to appeal to Linux users with new cross-platform "PowerShell" which you have to install separately. Windows PowerShell is increasingly falling behind that in performance and compatibility. We're heading away from "PowerShell included" back to the old world of "if you have to download and install something to get away from this abandonware legacy thing, why not Python or node.js?". > "a superior alternative to Bourne shells which only got traction on Windows because Bourne is too deeply embedded in the Unix world"?" It's a superior alternative to Bourne shells on Windows, and because it's basically Microsoft-Perl or Microsoft-Clunky-Python as well as being a shell, as in - it's more capable than Unix shell because it's a kitchen sink of scripting and programming language as well as command line.