5 ms·

I've often wondered why powershell hasnt taken off on linux/mac. I'd guess MS would have a good case for investing there (given, eg., linux usage on azure). Pa

I've often wondered why powershell hasnt taken off on linux/mac. I'd guess MS would have a good case for investing there (given, eg., linux usage on azure). Particularly in the recent history of "every day, another shell" on linux/mac. Powershell seems to solve the problem being resolved in rust,go,scala,... over-and-over. Why not just use that?

lloydatkinson 5y ago
Powershell runs on Linux and macos too because of .NET Core/5+. The real reason is likely the same sort of people that are still typing Micro$oft in <current year> and keep spreading FUD that .NET isn't OS.
- yebyen 5y ago
  I have never heard anyone "spreading FUD that .NET isn't OS" but I have heard plenty of times from Mac and Linux users, "why would you want to use PowerShell" and I am mining this thread for answers, because I honestly don't know for myself. And it's objectively true that .NET/PowerShell is targeting Windows users, (which if you're Microsoft, why wouldn't you do that?) so, assuming that you don't care about interoperability with Windows users, don't use Windows yourself, don't have any customers asking for PowerShell support for whatever XYZ widget you build... what are the compelling reasons to run PS on Linux or Mac? Setting up .NET is an investment, and learning to program it is an investment, people invest in the Go, Rust, Ruby, Python, TypeScript, JS ecosystems because they are generally useful, and that extends to Windows people, but if I'm building a product targeting Mac or Linux (servers), what is the incentive for me to make my customers install the .NET runtime at the proper version and fiddle with .exe files (or am I completely off base about how it works?)
  - oaiey 5y ago
    .NET is still ignored a lot as consequence of FUD. But you are right, there is not much FUD. The rest is spot on. Powershell has it space when you need manage windows and Linux Server using a shared platform. And that is where Microsoft puts it. As a .NET based management platform for services and operating systems on both, Linux and Windows.
  - lloydatkinson 5y ago
    > I have never heard anyone "spreading FUD that .NET isn't OS" Observe /r/programming or HN for long enough. > .NET/PowerShell is targeting Windows users, (which if you're Microsoft, why wouldn't you do that?) Azure, for one. Azure's primary and preferred method of interaction instead of it's UI is with it's API, which is also available fully wrapped up as Powershell cmdlets which again run on all three OS's. > Setting up .NET is an investment, and learning to program it is an investment, > make my customers install the .NET runtime at the proper version and fiddle with .exe files You don't, you either get them to install it's APT .deb file or <insert distro packaging format here> or wget the dotnet-install script. OR, you just build your app with .NET runtime packaged in .so file alongside your app. Running the applications involves typing ./my-application which then runs the ELF binary. There is no .exe unless it's on Windows. It's the same install and run story that any of the other languages listed mentioned.
    - yebyen 5y ago
      > Observe /r/programming or HN for long enough. Well, I haven't seen those commenters before, and I'm still not excited about using .NET, (and I'm the type of person who you'd expect to be getting excited about a strongly-typed shell) so either that's not the driving factor here, or... > Azure, for one. Azure's primary and preferred method of interaction instead of it's UI is with it's API, which is also available fully wrapped up as Powershell cmdlets which again run on all three OS's. I have been getting into Azure, and I've found the `az cli` somewhat lacking, for example "why is the default 'get' behavior emitting a huge blob of JSON instead of printing a table that humans can read?" and I thought, maybe this is a reflection of the fact that they'd prefer you write an API client and build it into a portal for your customers rather than asking people on your team to use the CLI directly? Seems you've confirmed this for me here. It would be nice to use a strongly typed interface rather than parsing JSON blobs, maybe I will end up checking that out! Thanks :) > > make my customers install the .NET runtime at the proper version and fiddle with .exe files > > You don't, you either get them to install it's APT .deb file or <insert distro packaging format here> or wget the dotnet-install script. OR, you just build your app with .NET runtime packaged in .so file alongside your app. My point was, they do need to have or obtain the correct version of the runtime to go with your app, and if there are different apps with different maintenance cycles, that might mean you need multiple runtimes installed and a way of switching between them. That's a big deal! If I want to adopt a runtime, I hope I'm adopting it for more than just one app. Now all of these apps need to be on the treadmill, actively maintained, or some upgrade might break, pinning me to a particular version, and then I'm stuck. If there was ever a compelling problem to solve, it's here, although based on the breadth of languages and frameworks that still experience this problem in one way or another, I think it's likely unsolvable. You either need someone (a distro) running the compilers and checking that things still work together in concert with the maintainers of the upstream software, or you need to be statically linking, or get yourself something like venv/rvm that makes managing multiple versions of a runtime a low-overhead activity (so you can have 4 versions if that is what is required for your different maintenance cycles across different services, without needing to break those services out onto four separate servers just to accommodate the language runtime differences.) Not to rule it out, does the .NET ecosystem have a great answer to this already? (Edit: I guess "the web application" is the answer, broadly speaking! "Users" don't have to install anything besides a browser.) > Running the applications involves typing ./my-application which then runs the ELF binary. There is no .exe unless it's on Windows. It's the same install and run story that any of the other languages listed mentioned. So I'm assuming you can also statically link your .NET binaries and emit a fat binary that will work anywhere, but at tremendous cost in terms of disk usage, (but you makes your choices and you takes your chances) – like I was saying, this is not a problem unique to .NET either, Go binaries from the likes of GCloud and Azure for interacting with their APIs are all enormous, because they want to avoid this problem with their users and they have lots of libraries to pull in. For me, the killer feature that makes Ruby ecosystem "worth adopting" is open source. You know how rare it is to encounter some Ruby gem which is not open to changes and inspection? I can think of exactly one time I found this, it did block me from using some software (AppDynamics bundled a native ext. with their Rubygem, it had wicked thread safety issues if you upgraded Ruby past a certain version... they did not provide the source, so enterprising customers couldn't fix the problem for themselves and contribute it upstream...) I've been using Ruby professionally for about 14 years, and I saw this issue exactly once. And that was a choice that one vendor made, and such a rare event that I would never think to let it reflect badly on the language. Go does not seem to have these issues as commonly (where somebody distributes a go package as binary-only) even though the language is not interpreted so it can happen and it wouldn't be unusual or even "against the grain." This is why I thought of Ruby being primarily executable as an interpreted language as "the guard" against this sort of thing happening in Ruby ecosystem.
- beagle3 5y ago
  My answer is: I’ve been using sh/csh/tcsh/bash/zsh/fish for almost 30 years at this point. I’ve used powershell on windows, and it’s not bad, but it doesn’t give me anything useful on Linux I don’t already have with bash or zsh. And whenever a script needs more power, I reach for Python. (Maybe I should xonsh instead? But the question for me isn’t “why not pwsh?” But rather “why pwsh?”)
- jmull 5y ago
  The actual real reason is *nix had mature shell scripting many years before powershell was conceived. For powershell to "take off" on non-Windows platforms, many people need to adopt it and for many people to adopt it, it needs to solve some critical problems the existing solutions don't solve well. I think pretty clearly, powershell doesn't do that. (I think I personally would be an easy candidate to use it on Mac... I know/use powershell pretty much daily at my day job -- so there's a minimal learning curve and I still haven't seen any reason to use it on various Mac side projects and jobs. I just do bash/zsh scripts. If it was built in maybe I'd reconsider.) For myself, I know powershell reasonably well from my day job Sometimes people will switch to something new just because it's new, but for , generthe new thing has to have some
cobbal 5y ago
As a mac user, I was going to provide a flippant answer, but I decided to look into it instead. Personally, I use zsh or a custom built shell scripting library inside swift. Always like to see improvements to shells though. Googled for it and got a dozen guides on how to install it in mac, but none that actually explained how to use it. (One video result looked like it might have some info, but to me that doesn't count as documentation). All the documentation on powershell is targeted at windows devs, and it's just a very different culture. Flippant answer: the CapitalizationConvention-ShouldScare-EveryoneAway
- code_runner 5y ago
  Imo your flippant answer is bang on
- nojito 5y ago
  You really don’t need any online documentation. Just use Get-Help and you’re off to the races.
  - CWuestefeld 5y ago
    This, in conjunction with the cmdlets and their parameters being something approximating English, with semi-standard verbs, makes things a lot more discoverable than Linux seems to me.
- mjburgess 5y ago
  Incidentally, I needed to teach myself PS for an azure-focused client of mine -- and I did so on mac (incidentally, making notes in a jupyter notebook with PS backend). It's a weird language, but I always reminded myself of its competitor: bash -- which is perhaps an order of magnitude more weird. It feels like it could be a "shell language for the cloud", ie., the language for cross-OS cloud automation work.
  - vxNsr 5y ago
    > It feels like it could be a "shell language for the cloud", ie., the language for cross-OS cloud automation work. Isn't that terraform?
randomifcpfan 5y ago
Would want to look at how people use Power Shell on Windows and compare to how people use bash/tools/procfs/Python/C on *nix. I think that, on *nix, Power Shell loses to cli tools/bash/procfs for trivial problems, to Python for simple problems, and to native strongly typed languages for complicated problems. Many Windows APIs are COM based, for both arguments and results, so an OO-based scripting language is helpful. Unix APIs tend to be less strongly typed. Mostly lists of lists of strings and ints. Is there really a recent increase in shells on Linux? I can only think of zsh and fish.
- Macha 5y ago
  Debian moved to dash as the default shell a few years ago, nushell gets some users, fish has moved from niche to one of the big players, and yes, some people also use powershell on Linux. You could argue it's just a changing of the guard as things like csh or ksh die off on Linux and get fish/pwsh take their place as the second tier shells in popularity, but it did feel like many years we were in a bash monoculture with zsh only surviving by being sufficiently compatible.
- syshum 5y ago
  In mixed enviroments being able to use Powershell on both Linux and Windows allows for people to only have to learn one scripting environment, and allow you to share functions, modules, and tooling between the systems. that alone is a big WIN for PS imo Also I find Powershell to be more enjoyable to use (I like the verbosity, the help system, and passing objects instead of text streams.. I know I am crazy), and easier to train new Admins on PS than bash or python.
WaxedChewbacca 5y ago
wokwokwok 5y ago
Look, I’ve written a lot of powershell, and I don’t mind it at all, but its not surprising at all to me. Powershell isn’t in the same problem domain as rust/go/Scala/python. The niche it fills is “calling windows apis from c++” or, more recently, c#. It’s less effort than that, so it’s useful, on windows. It is not less effort than using say, a bash script on other platforms because it: - does not provide unique access to proprietary windows apis (they don’t exist) - is not installed by default - does not conform to any standards other than it’s own - no package manager that works The question you should ask is: why given that, would you, given that you must install something, choose to install and use powershell instead of python? There’s no reason. You’d have to specifically like powershell to bother. Most people don’t care enough to be bothered. Surprise level: 0.
- frogger8 5y ago
  Perfectly stated! Powershell is fantastic…for windows.
- Macha 5y ago
  Also if you look at interactive shells, which have the lower bar to people trying them out (as seen by fish, nushell, etc. picking up users in recent years), powershell is actually quite clunky as an interactive shell. It doesn't appear to have completions matching those shells, the command names are quite tedious for those that don't have built in unix-y aliases, it doesn't provide a facility for common shell shortcuts like "run this one command with a modified environment", etc.
  - juki 5y ago
    > It doesn't appear to have completions matching those shells What kind of completions do you mean? PowerShell has completion for commands, parameter names and arguments. You can define arbitrary script blocks to do custom completion (or for simple cases just use `ValidateSet`). They can be defined either in the script/function itself, or separately with `Register-ArgumentCompleter` (that also works for non-PowerShell programs).
    - 5y ago
archi42 5y ago
wokwokwok, cobbal and oefrha made excellent points in the sibling comments. The only thing new PowerShell brings to the table is to pipe structured objects instead of only arbitrary data. And for that you don't need PowerShell itself: The power of the Linux shell isn't really the shell itself, it's in the powerful tools you can call from it and how you can interact with the Kernel and other components of the OS. The shell just gives you a simple interface and the ability to glue lots of small tools together. I think the reason we don't have a popular PowerShell clone, a "shell-with-objects", is that we would need to change how a lot of these tools handle basic data IO. I would love to see that, because sometimes parsing text is annoying, mental overhead; especially when filenames containing whitespaces are involved; but then there are always scripting languages waiting to help out (e.g. I tend to use perl kind of "super powerful shell script"). Also, what's "every day, another shell"? I have been using bash nearly two decades now, with the odd script written for pure sh in case it might be shipped to a customer. After Manjaro duped my into using zsh (I think they changed the default) I am now growing fond of the improved completion and history; but I could still stick to bash without being on a deprecated track.
nwallin 5y ago
I don't have any experience with iOS, and haven't scripted in anger in powershell. Linux and its ecosystem evolved alongside bash. If somebody tried to make a thing, and said thing was difficult to script with bash, nobody used the thing. They would say it's "hard to use". So system facilities and applications that don't script well with a shell script like bash (or csh or zsh to tcsh...) never survived. Basically, everything in linux automation is a nail, and bash is a very good hammer. DOS/Windows has had .bat scripts forever, which is not a particularly good hammer, but more importantly, Windows automation is very much not-nail like. You need a wrench and a socket set for many tasks, and CMD simply doesn't do that very well. (neither does bash for that matter) So powershell is a godsend. Meanwhile, us linux folks are sitting here with our hammer and all of our nails, and ... well, while I see that sometimes, it's maaaaybe nice to have a screwdriver as well, I certainly don't see the need for powershell. > Particularly in the recent history of "every day, another shell" on linux/mac. You'll note that all of these shells try to be a better hammer. None of them go in the direction that powershell goes in.

lloydatkinson 5y ago

Powershell runs on Linux and macos too because of .NET Core/5+. The real reason is likely the same sort of people that are still typing Micro$oft in <current year> and keep spreading FUD that .NET isn't OS.

yebyen 5y ago
I have never heard anyone "spreading FUD that .NET isn't OS" but I have heard plenty of times from Mac and Linux users, "why would you want to use PowerShell" and I am mining this thread for answers, because I honestly don't know for myself. And it's objectively true that .NET/PowerShell is targeting Windows users, (which if you're Microsoft, why wouldn't you do that?) so, assuming that you don't care about interoperability with Windows users, don't use Windows yourself, don't have any customers asking for PowerShell support for whatever XYZ widget you build... what are the compelling reasons to run PS on Linux or Mac? Setting up .NET is an investment, and learning to program it is an investment, people invest in the Go, Rust, Ruby, Python, TypeScript, JS ecosystems because they are generally useful, and that extends to Windows people, but if I'm building a product targeting Mac or Linux (servers), what is the incentive for me to make my customers install the .NET runtime at the proper version and fiddle with .exe files (or am I completely off base about how it works?)
- oaiey 5y ago
  .NET is still ignored a lot as consequence of FUD. But you are right, there is not much FUD. The rest is spot on. Powershell has it space when you need manage windows and Linux Server using a shared platform. And that is where Microsoft puts it. As a .NET based management platform for services and operating systems on both, Linux and Windows.
- lloydatkinson 5y ago
  > I have never heard anyone "spreading FUD that .NET isn't OS" Observe /r/programming or HN for long enough. > .NET/PowerShell is targeting Windows users, (which if you're Microsoft, why wouldn't you do that?) Azure, for one. Azure's primary and preferred method of interaction instead of it's UI is with it's API, which is also available fully wrapped up as Powershell cmdlets which again run on all three OS's. > Setting up .NET is an investment, and learning to program it is an investment, > make my customers install the .NET runtime at the proper version and fiddle with .exe files You don't, you either get them to install it's APT .deb file or <insert distro packaging format here> or wget the dotnet-install script. OR, you just build your app with .NET runtime packaged in .so file alongside your app. Running the applications involves typing ./my-application which then runs the ELF binary. There is no .exe unless it's on Windows. It's the same install and run story that any of the other languages listed mentioned.
  - yebyen 5y ago
    > Observe /r/programming or HN for long enough. Well, I haven't seen those commenters before, and I'm still not excited about using .NET, (and I'm the type of person who you'd expect to be getting excited about a strongly-typed shell) so either that's not the driving factor here, or... > Azure, for one. Azure's primary and preferred method of interaction instead of it's UI is with it's API, which is also available fully wrapped up as Powershell cmdlets which again run on all three OS's. I have been getting into Azure, and I've found the `az cli` somewhat lacking, for example "why is the default 'get' behavior emitting a huge blob of JSON instead of printing a table that humans can read?" and I thought, maybe this is a reflection of the fact that they'd prefer you write an API client and build it into a portal for your customers rather than asking people on your team to use the CLI directly? Seems you've confirmed this for me here. It would be nice to use a strongly typed interface rather than parsing JSON blobs, maybe I will end up checking that out! Thanks :) > > make my customers install the .NET runtime at the proper version and fiddle with .exe files > > You don't, you either get them to install it's APT .deb file or <insert distro packaging format here> or wget the dotnet-install script. OR, you just build your app with .NET runtime packaged in .so file alongside your app. My point was, they do need to have or obtain the correct version of the runtime to go with your app, and if there are different apps with different maintenance cycles, that might mean you need multiple runtimes installed and a way of switching between them. That's a big deal! If I want to adopt a runtime, I hope I'm adopting it for more than just one app. Now all of these apps need to be on the treadmill, actively maintained, or some upgrade might break, pinning me to a particular version, and then I'm stuck. If there was ever a compelling problem to solve, it's here, although based on the breadth of languages and frameworks that still experience this problem in one way or another, I think it's likely unsolvable. You either need someone (a distro) running the compilers and checking that things still work together in concert with the maintainers of the upstream software, or you need to be statically linking, or get yourself something like venv/rvm that makes managing multiple versions of a runtime a low-overhead activity (so you can have 4 versions if that is what is required for your different maintenance cycles across different services, without needing to break those services out onto four separate servers just to accommodate the language runtime differences.) Not to rule it out, does the .NET ecosystem have a great answer to this already? (Edit: I guess "the web application" is the answer, broadly speaking! "Users" don't have to install anything besides a browser.) > Running the applications involves typing ./my-application which then runs the ELF binary. There is no .exe unless it's on Windows. It's the same install and run story that any of the other languages listed mentioned. So I'm assuming you can also statically link your .NET binaries and emit a fat binary that will work anywhere, but at tremendous cost in terms of disk usage, (but you makes your choices and you takes your chances) – like I was saying, this is not a problem unique to .NET either, Go binaries from the likes of GCloud and Azure for interacting with their APIs are all enormous, because they want to avoid this problem with their users and they have lots of libraries to pull in. For me, the killer feature that makes Ruby ecosystem "worth adopting" is open source. You know how rare it is to encounter some Ruby gem which is not open to changes and inspection? I can think of exactly one time I found this, it did block me from using some software (AppDynamics bundled a native ext. with their Rubygem, it had wicked thread safety issues if you upgraded Ruby past a certain version... they did not provide the source, so enterprising customers couldn't fix the problem for themselves and contribute it upstream...) I've been using Ruby professionally for about 14 years, and I saw this issue exactly once. And that was a choice that one vendor made, and such a rare event that I would never think to let it reflect badly on the language. Go does not seem to have these issues as commonly (where somebody distributes a go package as binary-only) even though the language is not interpreted so it can happen and it wouldn't be unusual or even "against the grain." This is why I thought of Ruby being primarily executable as an interpreted language as "the guard" against this sort of thing happening in Ruby ecosystem.
beagle3 5y ago
My answer is: I’ve been using sh/csh/tcsh/bash/zsh/fish for almost 30 years at this point. I’ve used powershell on windows, and it’s not bad, but it doesn’t give me anything useful on Linux I don’t already have with bash or zsh. And whenever a script needs more power, I reach for Python. (Maybe I should xonsh instead? But the question for me isn’t “why not pwsh?” But rather “why pwsh?”)
jmull 5y ago
The actual real reason is *nix had mature shell scripting many years before powershell was conceived. For powershell to "take off" on non-Windows platforms, many people need to adopt it and for many people to adopt it, it needs to solve some critical problems the existing solutions don't solve well. I think pretty clearly, powershell doesn't do that. (I think I personally would be an easy candidate to use it on Mac... I know/use powershell pretty much daily at my day job -- so there's a minimal learning curve and I still haven't seen any reason to use it on various Mac side projects and jobs. I just do bash/zsh scripts. If it was built in maybe I'd reconsider.) For myself, I know powershell reasonably well from my day job Sometimes people will switch to something new just because it's new, but for , generthe new thing has to have some

cobbal 5y ago

As a mac user, I was going to provide a flippant answer, but I decided to look into it instead. Personally, I use zsh or a custom built shell scripting library inside swift. Always like to see improvements to shells though. Googled for it and got a dozen guides on how to install it in mac, but none that actually explained how to use it. (One video result looked like it might have some info, but to me that doesn't count as documentation). All the documentation on powershell is targeted at windows devs, and it's just a very different culture. Flippant answer: the CapitalizationConvention-ShouldScare-EveryoneAway

code_runner 5y ago
Imo your flippant answer is bang on
nojito 5y ago
You really don’t need any online documentation. Just use Get-Help and you’re off to the races.
- CWuestefeld 5y ago
  This, in conjunction with the cmdlets and their parameters being something approximating English, with semi-standard verbs, makes things a lot more discoverable than Linux seems to me.
mjburgess 5y ago
Incidentally, I needed to teach myself PS for an azure-focused client of mine -- and I did so on mac (incidentally, making notes in a jupyter notebook with PS backend). It's a weird language, but I always reminded myself of its competitor: bash -- which is perhaps an order of magnitude more weird. It feels like it could be a "shell language for the cloud", ie., the language for cross-OS cloud automation work.
- vxNsr 5y ago
  > It feels like it could be a "shell language for the cloud", ie., the language for cross-OS cloud automation work. Isn't that terraform?

randomifcpfan 5y ago

Would want to look at how people use Power Shell on Windows and compare to how people use bash/tools/procfs/Python/C on *nix. I think that, on *nix, Power Shell loses to cli tools/bash/procfs for trivial problems, to Python for simple problems, and to native strongly typed languages for complicated problems. Many Windows APIs are COM based, for both arguments and results, so an OO-based scripting language is helpful. Unix APIs tend to be less strongly typed. Mostly lists of lists of strings and ints. Is there really a recent increase in shells on Linux? I can only think of zsh and fish.

Macha 5y ago
Debian moved to dash as the default shell a few years ago, nushell gets some users, fish has moved from niche to one of the big players, and yes, some people also use powershell on Linux. You could argue it's just a changing of the guard as things like csh or ksh die off on Linux and get fish/pwsh take their place as the second tier shells in popularity, but it did feel like many years we were in a bash monoculture with zsh only surviving by being sufficiently compatible.
syshum 5y ago
In mixed enviroments being able to use Powershell on both Linux and Windows allows for people to only have to learn one scripting environment, and allow you to share functions, modules, and tooling between the systems. that alone is a big WIN for PS imo Also I find Powershell to be more enjoyable to use (I like the verbosity, the help system, and passing objects instead of text streams.. I know I am crazy), and easier to train new Admins on PS than bash or python.

WaxedChewbacca 5y ago

wokwokwok 5y ago

Look, I’ve written a lot of powershell, and I don’t mind it at all, but its not surprising at all to me. Powershell isn’t in the same problem domain as rust/go/Scala/python. The niche it fills is “calling windows apis from c++” or, more recently, c#. It’s less effort than that, so it’s useful, on windows. It is not less effort than using say, a bash script on other platforms because it: - does not provide unique access to proprietary windows apis (they don’t exist) - is not installed by default - does not conform to any standards other than it’s own - no package manager that works The question you should ask is: why given that, would you, given that you must install something, choose to install and use powershell instead of python? There’s no reason. You’d have to specifically like powershell to bother. Most people don’t care enough to be bothered. Surprise level: 0.

frogger8 5y ago
Perfectly stated! Powershell is fantastic…for windows.
Macha 5y ago
Also if you look at interactive shells, which have the lower bar to people trying them out (as seen by fish, nushell, etc. picking up users in recent years), powershell is actually quite clunky as an interactive shell. It doesn't appear to have completions matching those shells, the command names are quite tedious for those that don't have built in unix-y aliases, it doesn't provide a facility for common shell shortcuts like "run this one command with a modified environment", etc.
- juki 5y ago
  > It doesn't appear to have completions matching those shells What kind of completions do you mean? PowerShell has completion for commands, parameter names and arguments. You can define arbitrary script blocks to do custom completion (or for simple cases just use `ValidateSet`). They can be defined either in the script/function itself, or separately with `Register-ArgumentCompleter` (that also works for non-PowerShell programs).
  - 5y ago

archi42 5y ago

wokwokwok, cobbal and oefrha made excellent points in the sibling comments. The only thing new PowerShell brings to the table is to pipe structured objects instead of only arbitrary data. And for that you don't need PowerShell itself: The power of the Linux shell isn't really the shell itself, it's in the powerful tools you can call from it and how you can interact with the Kernel and other components of the OS. The shell just gives you a simple interface and the ability to glue lots of small tools together. I think the reason we don't have a popular PowerShell clone, a "shell-with-objects", is that we would need to change how a lot of these tools handle basic data IO. I would love to see that, because sometimes parsing text is annoying, mental overhead; especially when filenames containing whitespaces are involved; but then there are always scripting languages waiting to help out (e.g. I tend to use perl kind of "super powerful shell script"). Also, what's "every day, another shell"? I have been using bash nearly two decades now, with the odd script written for pure sh in case it might be shipped to a customer. After Manjaro duped my into using zsh (I think they changed the default) I am now growing fond of the improved completion and history; but I could still stick to bash without being on a deprecated track.

nwallin 5y ago

I don't have any experience with iOS, and haven't scripted in anger in powershell. Linux and its ecosystem evolved alongside bash. If somebody tried to make a thing, and said thing was difficult to script with bash, nobody used the thing. They would say it's "hard to use". So system facilities and applications that don't script well with a shell script like bash (or csh or zsh to tcsh...) never survived. Basically, everything in linux automation is a nail, and bash is a very good hammer. DOS/Windows has had .bat scripts forever, which is not a particularly good hammer, but more importantly, Windows automation is very much not-nail like. You need a wrench and a socket set for many tasks, and CMD simply doesn't do that very well. (neither does bash for that matter) So powershell is a godsend. Meanwhile, us linux folks are sitting here with our hammer and all of our nails, and ... well, while I see that sometimes, it's maaaaybe nice to have a screwdriver as well, I certainly don't see the need for powershell. > Particularly in the recent history of "every day, another shell" on linux/mac. You'll note that all of these shells try to be a better hammer. None of them go in the direction that powershell goes in.