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?
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.
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).
ls -l
-1 (List one entry per line)
-A --almost-all (Show hidden except . and ..)
-a --all (Show hidden)
-B --ignore-backups (Ignore files ending with ~)
…and 51 more rows
In Powershell, if I type Get-ChildItem -<tab>
It just cycles through options apparently abitrarily. The first suggestion is "-Path", and it offers no facility to provide explanatory information.
In principle there isn't anything that would stop one from making that. PowerShell has history info available, and help messages/docstrings can be given for parameters (`Get-Help command -full` will show them if available).
"No it doesn't, because it's not exactly like the thing that I am used to. In fact, it doesn't have solutions for the limitations it eliminates! Poor."
I heard the same arguments when, for example, SolidWorks with its true construcive solid geometry (CSG) 3D modelling swept away the old 2D "electronic paper" tools such as AutoCAD. The old guys complained in exactly the same way.
"What if I just want to draw the outline by hand? SolidWorks is terrible at that!".
"Umm... it can draw arbitrary cross-sections automatically in seconds!"
"Yes, but I can't control things the way that I'm used to!"
Etc...
Passing objects by default is a nice idea to enhance pipes... but how about going beyond pipes? :)
Flippant answer: the CapitalizationConvention-ShouldScare-EveryoneAway
Just use Get-Help and you’re off to the races.
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.
Isn't that terraform?
My very limited experience has been: look up problem, find likely solution, enter 60-character command specific to this niche issue that I'll only ever have to use again in this exact situation, which is now solved until next reinstall.
Having said that, those are the only situations in which I've needed to use powershell.
Powershell in Depth [1]
Powershell Cookbook [2]
[1] https://www.manning.com/books/powershell-in-depth
[2] https://www.oreilly.com/library/view/powershell-cookbook-4th...
I'd even argue that, between PowerShell's kinda-guessable commands and parameter names (as contrasted to bash/linux) and ubiquitous --help, PS makes it easier (relatively) to discover a solution on your own.
I guess a big part of this is what your native language is.
Yeah, if I'm trying to find something out on Unix-y world I have the escalation tree of
1. Tab Completion shows summaries
2. Still not clear? --help will usually print out an overview
3. Really still not clear? "man" to the rescue.
- Write-Output and friends try to be smart and print different things situationally. I hate "smart".
- Try to get something akin to set -e -o pipefail, i.e. exit if a command fails. Pain.
- Try to get something akin to set -x for tracing. There's Set-PSDebug, but the trace level also applies to all the cmdlets, so say you use Expand-Archive, suddenly you have a million lines of crap in your trace you don't give a shit about.
In general, IMO the biggest advantage of PowerShell compared to scripting languages like Python/Perl is the ability to natively interact with Windows' COM stuff. That advantage is nonexistent on *nix.
After waiting for the installation to do god knows what for what felt like ever (and I was running an 8 core Xeon with a fast NVMe drive at the time...) I attempted to connect to the Office 365 tenant to do something.
Since it was my first attempt at running this on Linux, I was following along with the MS docs (actual docs.ms, not the TechNet circus) and I started getting uncomfortable with statements along the lines of "this should work". I mean, if you're not sure, who can be?
Anyway, it managed to install whatever libraries it wanted, so I was ready to go. But everything ended abruptly with some "incorrect credentials" or similar. The credentials were, of course, OK (they worked fine in the web-based admin console). But after some digging, it turned out that, contrary to what the MS docs said, you can't connect to Office365 from linux...
I'm quite sad that gdb doesn't have something similar: 'step in my application only' no I don't want to step into the STL shared pointer dereference implementation for the n-th time!
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.
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.
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.
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.
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.
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?)
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.
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.
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.
(Maybe I should xonsh instead? But the question for me isn’t “why not pwsh?” But rather “why pwsh?”)
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