PowerShell as a scripting language is a major PITA. On one project I had to maintain a PowerShell script for provisioning. The provisioning takes 2 to 3 hours. After 2 hours the script would abruptly quit because of some syntax error. 2 hours wasted.
A lot of Microsoft plugins have PowerShell plugins. This is what makes PowerShell valuable, not some attribute of PowerShell itself.
Really what Microsoft should have done is to make those plugins available to C#. Then make C# usable for scripting purposes -- C# is as easy as most scripting languages in any case, and now with "top-level statements" you don't have to write classes. Make C# usable like Dino for TypeScript (i.e., transparent compilation). Then any syntax errors in the script can be caught ahead of time, instead of after 2 hours of running.
PowerShell as a _shell_ language though is really cool. Yes, scripting large scripts can be cumbersome, but actually having a PowerShell prompt beats having a cmd.exe prompt any day hands down!
Some of the things are not... ideal. And there's a bunch of legacy stuff in modern powershell that we could do without, but a REPL scripting language with pipe semantics is really useful on a day-to-day basis.
I'm not sure C# would work as a shell language at all.
Why do people keep complaining about PowerShell verbosity? There are default aliases for common commands, tab completion of everything, and user-defined aliases. PowerShell is only idiomatically verbose so people can actually read it, unlike your average unix shell command.
Because they start at the conclusion and work backwards.
"It isn't what I'm used to, therefore bad, now let me figure out why." After that the length of commands is an easy target, in particular if you don't know enough about it to criticize it for anything substantive.
It's a shell, I don't want to write a novel to get something done. bash is a bunch of small composable binaries that chain together easily. powershell is, was? not. length of commands IS important imho for a shell as I want to be able to quickly type out what I need to do and then move on
I can code-golf in powershell. You could too, if you tried.
Powershell is based on small composable commands that are easy to chain together - as you would know if you've used it at all.
Valid criticisms exist of powershell. It baffles me why Linux refuseniks trot out such easily-discounted objections. My belief is that it's a figleaf over a political position: "I will never use a Microsoft product". We're on HN; that's an acceptable position. Why bullshit?
Because it's painful. The tab completion works in a weird way by filling the first available option when there are many, instead of proposing them all, meaning it's outright harmful in 90% of the cases, and is completely different than the established norms in *nix land. Aliases aren't recommended because they remove the main advantage of the verbosity, readability.
A) Tab completion behavior in PowerShell is configurable
2) You just keep hitting tab until you get the one you want. This is the tab completion behavior of the Windows command line since it added tab completion.
For many years, the aliases were worse than the problem. Aliasing `curl` to `Invoke-WebRequest` without also aliasing the flags was a crime against usability.
That said, tab completion works, and I used PowerShell on macOS for a long time with no complaints.
because when I am in a shell I don't want to spend days typing out and tabbing forever trying to write some quick one liner command I'll never look at again. I just want a bunch of quick and easy to compose functions to just do what I want, and then move on. I don't need it to be readable, just quick and functional which bash is.
> because when I am in a shell I don't want to spend days typing out and tabbing forever trying to write some quick one liner command I'll never look at again.
Even without the hyperbole you have a comically exaggerated idea of how long it takes to write quick one-liners in PowerShell. For me personally, it helps a lot that I don't have to look up cryptic three-letter command names, obtuse switches, or the precise sed incantation to glue things together.
I’m sorry, maybe it’s just my experience at work where I have to use it, but I really honestly hate these bash emulations on windows. Like, I honestly don’t get the point. It will die with the stupidest errors due to mismatches between the underlying abstractions, it is slow and not even its terminal emulation is on point.
I will absolutely agree here. As a heavy Linux user, I always reach for PS over cmd when I need to work on a windows system
The main reason for this though, is that I can use some familiar Linux commands and I don't need to google how to list files in the current dir (PS and bash both have ls, among others)
When you run a PowerShell script, the entire thing gets loaded and parsed up front, so any syntax errors are going to happen immediately. Not saying you didn't see an error, but it probably wasn't a syntax error. (Beyond that, what language are you thinking of that doesn't stop when it hits errors in your program, and is that a good thing?)
Calling out to another script/dynamic powershell, or maybe is referring calling a cmdlet(is that what they were called) with the wrong arguments, goes power-shell check for that? It’s been almost a decade since I used it but I echo the sentiment. It was a difficult overly verbrose language that I avoided at all costs even going so far to install cygwin so I could use bash as a command line and scripting language
> Calling out to another script/dynamic powershell, or maybe is referring calling a cmdlet(is that what they were called) with the wrong arguments, goes power-shell check for that?
Can any scripting language check for that? It is beyond the scope of what an interpreter has available to it.
Yes! It's maddening trying to get the C# Powershell integration to use, Get-VM, for example. Especially in a way where it would work on somebody's else's computer.
> PowerShell as a scripting language is a major PITA.
Well, except this part.
> After 2 hours the script would abruptly quit because of some syntax error. 2 hours wasted.
As mentioned by another commenter, the PowerShell script is parsed up front, so it probably wasn't a syntax error. My guess is the script lacked error handling and some query or connection to a remote server failed.
> A lot of Microsoft plugins have PowerShell plugins. This is what makes PowerShell valuable, not some attribute of PowerShell itself.
There we go agreeing again. Although, PowerShell is effectively self-documenting, which is good for busy sysadmins.
> Really what Microsoft should have done is to make those plugins available to C#
A lot of them effectively are available to C#, such as System.DirectoryServices.*. In the early days of Active Directory, before PowerShell, this is how we did things. While fun for us programming nerds, it took a hell of a lot more time to write usable tools.
> C# is as easy as most scripting languages in any case
Hard disagree.
> Make C# usable like Dino for TypeScript (i.e., transparent compilation).
A more C#-like scripting language? I'm all for that, but why not just use TypeScript at that point (ala the JScript days).
> Then any syntax errors in the script can be caught ahead of time, instead of after 2 hours of running.
No, you run into the exact same challenges, whether it's PowerShell or C#.
IMHO, while I'd rather be doing C# programming any day of the week, PowerShell is more approachable for the vast majority of Windows sysadmins out there. Additionally, due to the command... verboseness of PowerShell, it is effectively self-documenting.
It might be best summarized by this partial quote: "PowerShell replaces fragile, prayer-based text parsing with pipelines of objects (structured data)"
His exact words are, "IMHO, while I'd rather be doing C# programming any day of the week, PowerShell is more approachable for the vast majority of Windows sysadmins out there."
IE, the vast majority of SYS admins aren't capable of approaching C#. Fully unsubstantiated heresay. If they can learn the cryptic nightmare that is power shell, they can certainly learn C#.
That's an extremely uncharitable interpretation of the quoted sentence. Just because X is more approachable than Y to a person doesn't mean they're incapable of approaching Y. The sentence makes no claims in regards to a sysadmin's capability.
I don’t want to write C#, I want something that can be that powerful when I need it, and be fast when I just want to get something done. Powershell is where I go in the Windows/M$ world, Python is where I go in the nix world.
There’s very few times that I need to write a Powershell script that runs like a daemon. I’m typically using it in a notebook in VSCode, but I do* have Kubernetes jobs that are written in Powershell that run periodically. They were quick and effortless to write, run fast (dotnet core,) and are easy for my team to understand if they want to modify them or someone needs to maintain them.
None of my team would willingly learn C#, nor would the business support them writing C#. A powershell script though? Fair game for anyone who wants to look at something new and innovative, it requires nothing if they use ISE, and if they want to, VSCode is already an approved app. Need a hosting platform? You can deploy on Kubernetes if you really want.
It’s a really big barrier to entry to force someone to use C#.
2. Aren't smart enough to learn C#, let alone well enough to do systems programming to replace PowerShell.
3. Don't have the time/desire to learn C#, even if they are capable.
4. Don't have the time to write systems management code in C#, as opposed to PowerShell.
Back when I started UNIX system administration, pretty much all sysadmins knew C and could write arbitrary system management utilities in C.
This is no longer the case, for better or worse, the world needs more sysadmins and Microsoft has released server software that can be managed by relatively minimally-skilled people who know how to Google and copy/paste code from websites.
>> Really what Microsoft should have done is to make those plugins available to C#
>A lot of them effectively are available to C#
True, though some of them aren't. I ran into one recently...setting the metric value for an ip interface (not a route, an interface). Powershell has that, C# does not, in any way that I can find.
> I ran into one recently...setting the metric value for an ip interface (not a route, an interface). Powershell has that, C# does not, in any way that I can find.
It can be done in C# via WMI (System.Management), but that's a strange old world if you're not used to it. But it's more convenient in Powershell because MS provide modules such as NetTCPIP so you don't need to touch WMI directly.
> Although, PowerShell is effectively self-documenting, which is good for busy sysadmins.
Oh no it isn't. Very basic stuff like Get-Something piped into a Remove-Something is, but beyond that, it gets complex quick. Add aliases, weird logic and limitations ( do you know you can't break out of a Foreach-Object?), and it quickly becomes an illegible mess that needs parsing, the same way Python might.
Furthermore, a lot depends on the cmdlet provider, and for instance the VMware ones are steaming piles of horseshit with inconsistent naming of parameters, broken async, and useless error management ( e.g. you get an error which says to check the inner exception, but it's empty and there's no way to get any detail whatsoever).
I would still take that over the cryptic -fHxC magic incantations of unix tools. Especially that you get unified help for all of them, readily available.
And I say that as someone who really doesn’t like windows (and thinks it is not fit for development at all) — but powershell is really a gem, if one gets over the at first strange syntax and actually looks into it.
But you can create PowerShell cmdlets using C#. If you're doing something that would really needs compile-time checks, simply extract the logic into a C# class inheriting from Cmdlet, and use that cmdlet in your scripts as needed:
I always enjoyed using it in reverse: when you build a .NET app it is very easy to add a CLI by exposing .NET code as cmdlets. This gives you documentation, completions and arg parsing for free while you stay in your application language. This is super useful.
Think of it as the .NET and PS equivalent of a manage.py script.
I agree that PS as a language is quite unusual (e.g. how it returns results) but on the other hand it’s concept of structured data also makes it powerful in ways that old-school Windows scripting or bash are not.
> The provisioning takes 2 to 3 hours. After 2 hours the script would abruptly quit because of some syntax error. 2 hours wasted
Anybody who designed such thing is bad. If stuff fail after 2 hours, you should be able to repeat it in idempotent way to just continue or you skip sections with parameters. Your syntax error problem is the same in any other shell, and in all dynamic languages.
> A lot of Microsoft plugins have PowerShell plugins. This is what makes PowerShell valuable, not some attribute of PowerShell itself.
Nonsense. I almost never use any of the "plugins". PowerShell on its own is game changer. Like the first dude already said, I have yet to see a problem that can't be done in 2-5 lines of code that is joy to read even in shorthand form, unlike countless magic chars, something that is known to be bad pattern in OOP.
> Really what Microsoft should have done is to make those plugins available to C#.
That is really NOT what Microsoft should have done instead of PowerShell, maybe alongside it. But since you have PowerShell, you don't need it that much. Besides, it already exists for almost decade.
> Then any syntax errors in the script can be caught ahead of time, instead of after 2 hours of running.
"There is a core architectural difference between Unix and Windows. Linux is a file-oriented OS and Windows is an API-oriented OS... The interesting thing is that the Windows approach is winning in the world and that makes PowerShell the best tool to the modern world. That sounds controversial but it is clearly true - most of the world is moving towards REST APIs returning structured objects (JSON documents)."
I'm not sure if the web could have worked any other way. RPC over HTTP and other message/pub-sub web technologies are largely used by enterprise-level applications, and not by modern web sites, correct?
I feel like it could be as easily argued that this approach is out of place on a local OS? Like, he's not totally wrong in a lot of ways, but that conclusion doesn't seem obvious to me.
I've noticed that some Microsoft employee blogs sound like this brainwashed corporate propaganda. I wonder if that type of ass-kissing is a prerequisite for promotions, or if the environment just tends to turn people?
> That sounds controversial but it is clearly true - most of the world is moving towards REST APIs returning structured objects (JSON documents).
Yes, but most RESTful apis are backed by an OS that is file oriented. Why? because the server deals with persistence while the API deals with compute. The Windows approach is not winning, hosting APIs on the file oriented OS works better for most. Why? because ultimately APIs are a compute problem not a persistence/storage problem. That said, for interacting with a RESTful api, what tool do you use? A programming language like JavaScript, C#, Python, or Java or a shell scripting language like bash, zsh, or PowerShell?
> Yes, but most RESTful apis are backed by an OS that is file oriented.
No? Most RESTful APIs are backed by databases. There's are a lot of variance there (Sql, NoSql, Cloudy Vs. Monothithic) but it isn't files. Even for file storage and delivery databases BLOB storage are often used rather than filesystem files.
When all you're using a filesystem for is storing a large continuous memory-mapped blob so that you can avoid interacting with the filesystem's APIs almost entirely, you aren't exactly championing a filesystem's utility in the internet age.
I'd go as far as to say that directly exposing filesystem files to the outside world is an anti-pattern (because it doesn't scale).
In the context of a file-based vs api-based shell scripting language, I think the point stands though. That's the main problem with the original statement, I think.
He's making a sales pitch rather than a factual statement. Linux is file-orientated but it is also API-orientated too. You cannot make syscalls via file descriptors, nor call shared objects via a fd. And most REST APIs in the world are running on top of Linux anyway.
I also think it is disingenuous to talk about HTTP APIs when talking about shell scripting as if it's something that needs to be built into the fabric of the shells design when HTTP APIs can be an abstraction that bolts on top. In fact that's exactly how a lot of CLI tools work (awscli, Terraform, even Powershell scripts will make those API calls in composed functions rather than natively from shell).
But even on a syscall level, Linux calls are way more barebones with not too user-friendly struct passings, etc. And due to their obsession with C, it is the same way in user space as well.
There is more 20 years of lessons learned between UNIX and NT though. Yeah Linux is a distinct OS but it was written to be a UNIX-clone whereas NT was designed to be a new OS from the ground up. However if you look at NT's spiritual godfather, VMS, that primarily written in C as well. Plus C++ doesn't magically fix the complaints you're making anyway.
It's also worth noting that Linux does have plenty of services that support RPCs too (X11, dbus, etc).
I'm not try to argue that Linux and Windows are equivalent though. Just that it's a little silly to argue that Linux can't do APIs.
I don't think I've ever come across a Windows API that was pleasant to use
CreateProcess is probably my favourite example
NT didn't inherit the problems of fork() with unix, but it's still a disaster of giant nested structures, combined with several different ways of creating lists of parameters (some params need quoting in weird ways, others need manual construction of arrays of null terminated strings)
whereas the POSIX APIs tend to be small, clean and simple
I'd go even further than that and say the web is a straightforward extension of Unix (basically adding URLs, which are amazing, and data driven UI)
... And I'll go even further and say that the Unix-y design CAUSED the success of the web, and if it were more like Windows, it wouldn't have scaled to be truly "world wide" !
I make a point of trying to use powershell for scripting stuff (instead of .bat files) and I kindof enjoy it, sometimes you get it to do something really smart. But I can never get my head around the concatenation rules, and how they work when you're passing stuff to legacy Cmd shell commands. Something to do with the & symbol, and maybe speechmarks? But the " and ' work very differently? The problems come when you want to pass multiple arguments to a Cmd command ...
The end result is I can't really ever get much done without a lot of googling. But thats par for the course these days I guess.
I think passing things to legacy cmd shell is a pain regardless of what language you do it from because the argument separating is up to each application.
I think there's power in the idea of structured objects in a shell, but is there a community that actually feels that PowerShell is a productive language? I'm biased coming from a Unix/bash background, but the times I've tried to get into PowerShell it's been quite clunky to use.
windows sysadmins like it, I guess. I serve mid-size banks and everyone is running mainframe and windows server. I use powershell + .net operationally in the same way a linux guy would use bash + python.
I know HN is a cloud-first developer community but there is an entire planet of businesses who are software consumers rather than software development firms. Windows is running /a lot/ of stuff even if you personally are not seeing it.
I know a lot of people don't like how verbose cmdlets are, but I find tab completing them to be just as fast and easier to remember than linux's alphabet of case sensitive switches that barely represent the underlying function.
Oh, and keep in mind that we evolved to this from .vbs, which was horrible.
it is absolutely useful, and starting as someone coming from Perl background and lots of it, PowerShell indeed is more than just a shell scripting. Sitting on top of .NET opens up to lots of functionality and on the automation front - POSH programs are much easier to read and maintain than bash/ksh/whateversh. So yes - it is very useful, and there is great community on both sides on the ocean (USA and Russia) that make heavy use of it.
Powershell is better than batch (.bat or .cmd) files.
I remember when I was new to shell scripts, thing like basic if loops felt clunky.
I would see something like "if [ -r $1 ] && [ -s $1 ]" and not even now where to start. Case statements I could only write by taking an existing one and modifying it.
These days I tend to use Python for all my scripting everywhere I can.
Short answer: yes. I will take PowerShell over bash/unix with its numerous antiquated footguns and coreutils' horrifically inconsistent and unreadable switches and clumsy text parsing any day.
Even within the unix community there are efforts like Elvish and NuShell trying to be more like PowerShell because it's obviously better.
I think it's one of those languages that you need to be immersed in to really benefit from. If you only use it occasionally then you will never internalize it enough to become proficient.
Most Microsoft sysadmins will be living and breathing it.
I have no idea about a community, but it does what I need quickly, and it does it the first time, instead of after ten extra minutes fiddling with awk/cut/sed. It clunks against Bash instincts, because it wasn't designed to be like Bash, because Bash wasn't designed to be like how programs actually operate.
For me, I switched over to Powershell Core, and as far as I'm concerned, it's way more productive for building situated software than the same gaggle of scripts that one gets with bash, in most cases.
param statements get you auto-complete, and docs. Powershell can just ingest and deal with JSON, and are one module away from doing the same with YAML.
Using % and ? (aliases for 'Foreach-Object' and 'Where-Object') ends up working very well for most data manipulations that one might be interested in.
It definitely has it's quirks as a language, but so does literally every shell in remotely common use.
And I'd say that Powershell is appropriate for non-trivial scripting use, as long as you familiarize yourself with the conventions for handing data to/from functions vs pipelines.
I've written more than one piece of above ad-hoc software in Powershell, though this is the only one I have in public: https://github.com/yumaikas/psi.
PowerShell is OK for small things, but it's cumbersome as hell when used for scripting and my goodness is it slow as dirt (50x slower) compared to even Python if you are processing a lot of items.
Another thing that bothers me about it is how many Windows system administrators claim they can "script" or "code" because they chain a few cmdlets together.
I want to like powershell because of the richer return types, but it has so many strange deviations from normal shell languages that it is hard to get productive in it.
I remember testing out some new languages and toolchains and following the guides, but I would often get many of them that would not work because I was using powershell. Powershell has different syntax for escaping (backtick), starting arrays (parens), etc., that makes many commands completely incompatible (even very short ones).
It is a complete re-imagining of what a shell scripting language is. Hardly surprising that it isn't backwards compatible or requires that you have to learn it.
People feel inconvenienced, which I get, but I feel like people don't give it enough credit for just how well-thought-out the design actually is.
Once you grasp it (which is admittedly easier if you know a Java-like language) your productivity skyrockets as commands are largely guessable and results are largely self-documenting. They have man-pages/get-help, but when an object is self-describing you don't need them as often.
The thing that disappoints me is that nobody from the *NIX world has tried to bring the same ideas there. They're good ideas.
> It is a complete re-imagining of what a shell scripting language is. Hardly surprising that it isn't backwards compatible
By why does having richer return types necessarily mean you need to deviate from most other languages for the escape character (backtick in Powershell, but usually backslash)? That doesn't seem related, and it greatly impacts the initial impressions people get.
> The thing that disappoints me is that nobody from the *NIX world has tried to bring the same ideas there. They're good ideas.
I agree, and I hope someone does. But if they do, I hope they just focus on the ideas, and leave out the small and unimportant incompatibilities powershell decided to add.
Honestly I don't see that going anywhere. It was said somewhere upthread that the real value of PS was in the Microsoft management modules, and I'd add the .NET library to that. If you're developing from scratch anything a script might want to use, your battle is going to be pretty uphill.
Unfortunately I have to agree. Current efforts are constrained by the desire to integrate with existing tooling and the text-parser-based approach of the unix interfaces in general (in particular sysfs and procfs on Linux).
I honestly think someone should do this "from scratch", as you say. I believe the effort would be worth it, but I doubt that the unix community would be amenable to the idea as it goes against their deeply held cultural traditions.
You may as well complain that the C guides didn't work in Java. A new language being compatible with an old one just weighs it down with forty years of cruft.
> You may as well complain that the C guides didn't work in Java.
Java borrowed a lot of syntax from C, and it has been very successful. If Java had instead taken the powershell approach of needlessly deviating with the syntax, it probably would not have become as popular as it did. So that example supports the opposite of what you thought it does.
You think I'm saying "don't be different for any reason." What I'm actually saying is "don't be different without a good reason". Python for example has been criticized for the breaking changes in version 3, which caused a lot of problems for the community, arguably without a good reason.
They shouldn't have "invented" a new language, they should have just embraced Python and started providing Microsoft supported modules for managing their products. That was a big miss.
Check out marcel: https://marceltheshell.org. This is a bash-like shell that pipes Python values, and you can write Python functions on the command line. It also has a Python API (a marcel module) that allows you to shell out far more cleanly than with Popen and friends.
I had to write a one-off script to convert a bunch of pptx files to pdf. (yeah I know pandoc exists, but it doesn’t always work as well as the real deal)
And to my surprise I found an example and could indeed open the file in the real office powerpoint, export as a pdf file and close it for each one of them with like 8 lines of code. Hell, I could have probably done it in parallel with a single flag (but that didn’t work on my version)
In a way, Windows out-UNIXed linux, because contrary to the latter’s philosophy, you don’t really get communication between components because everything is unstructured.
This is not an example of windows doing anything unix like. We simply have to take a different mindset when using Windows vs unix. Windows has always had a way to communicate between components and that it does better than anything else.
Up until the networked era at least where its communication between components was the source of thousands and thousands of vulnerabilities for Windows (ActiveX, thumbnail renderer, office apps embedded in emails...).
How is using multiple single-purpose tools to solve a problem not “unix-like”? Isn’t that the reason why people like POSIX-shells? It just happens that windows has better integration between even GUI apps, which is directly available from the shell.
Linux’s analog would be dbus, but that is not integrated with the shell natively.
With a unixy design, powerpoint would only edit powerpoint documents and it would send the data to other programs for printing or PDF creation.
In your case, the powerpoint program would never be called. You would simply send the powerpoint data to a program that converts powerpoint to maybe postscript, and you would send the postscript to ghostscript to make a PDF.
The unix like a approach is a bit more decoupled.
I cannot think of a single GUI program on linux that works this way (xfig maybe?) but in my mind, this would be the unix way. Of course by the mid 90s, the unix way lost out to the windows way so our GUI world on linux has something of a personality disorder.
It can’t really send powerpoint data to any other program, can it? It is a highly complex data format, and the logical conclusion would be n*m tools for interconverting between different formats — that would be bloated as hell. The fact is, sometimes we do need a program that fulfills a whole domain, not just a specific problem. For this conversion problem domain, there is pandoc for example.
I will be hated for this, but systemd would be another good example — you really can’t and should not subdivide such a complex problem into more specific ones. It should be tackled in one place (although systemd is quite modular besides that)
And then write another program for ppt-to-txt and every conceivable format? You might then say, okay, then first create an intermediary format but depending on program domain that may be more hassle than its worth it.
Powerpoint is made for correctly understanding .ppt(x) files. This complicated functionality should probably not be replicated at other programs as well.
Some UNIXes had something similar, NeWS, OpenSTEP DSOs (now macOS XPC),...
And even GNU/Linux could offer a similar experience if the ecosystem would actually buy into D-BUS or KParts, but that isn't never going to happen, and when only in a specific distribution, with the distribution specific apps, largely ignored by the remaining eco-system.
Besides that, it is somewhat ad-hoc. Like, ok, libreoffice has a cli interface (with their own conventions, mind you), but what about inkscape? Or a browser? And I’m sure there are plenty of programs under windows that also doesn’t provide such an interface, but I still feel that it is something linux should copy.
The difference is that all the tools you just used were created by Microsoft. It's essentially a curated experience. From that angle, it's a fucking mess. If Office didn't support PDFs and was created by a 3rd party. The integration would be really cool. As it stands, powerpoint should just have a bulk convert feature instead of scripting language hooks.
The reason bash is cool is because i can open it up, and run all these different programs written by different people, in different languages, for different use cases, and they all just work. It's the diversity of the ecosystem that makes the interoperability so cool. If it was all made by a single company, I'd say the usability is a fucking mess.
Someone else in another thread here that PS shines when you use the object models full-in. Personally I think bash shines in the opposite way as everything is a string and everything is a file, which as you mention, allows everything to work together
There is nothing inherent in PS’s model to disallow some third-party app from working. Also, having to create per-usecase bug-prone parsing for everything is pretty terrible. It is okay for copying a file or whatnot, but it is definitely not okay for more complex tasks. And indeed, for those you would just use a single-purpose tool, like pandoc for my given example.
I want to like PowerShell, but some basic design decisions really irk me. Specifically Verb-Noun command names seem so backwards. I want to start with the domain and then specify the action I want to perform in that domain. Noun-Verb would make so much more sense (and naturally group commands together when sorting alphabetically). Which brings up the other annoyance: long capitalized names with dashes in the middle. It's so annoying to type! Repeatedly typing dash followed by a shift-key combination adds enough friction to notice the burn. Finally, options are also too long. Compare `rm -rf` with `Remove-Item -Recurse -Force`. Capitals, dashes, long words... It's too much!
>Finally, options are also too long. Compare `rm -rf` with `Remove-Item -Recurse -Force`. Capitals, dashes, long words... It's too much!
but they're far more readable. You might be able to remember what -rf does for rm, but what does -o mean for curl? What's the difference between -o (lower case) and -O (upper case)?
I like PowerShell, but I'll agree with your first criticism, Verb-Noun makes less sense than Noun-Verb. At least it is pretty consistent about naming.
Complaining about long capitalized names with dashes in them is a little weird in a language that is both case-insensitive and has tab complete for everything though.
I admit the choice of case-insensitivity is questionable, although it is in keeping with Windows's history. I just think it is silly to complain about having to uppercase things when you, you know, don't have to do that.
But I didn't know I didn't have to do that! I admit to not being competent with it, but all the examples use title-case, so I thought that was required.
This would be my first question. Anybody naming things in IT knows that you go from big to small. From large domains to specific actions. Secondly, how are you supposed to learn which of the 40+(?) verbs to use. Store, Save, Put, Add. Update? In many cases it does not make any sense.
Have you tried reading the docs? A full list of approved verbs is available, and describes in detail when you should use them and what synonyms they should replace. It makes sense for anyone willing to spend a moment investigating why it's designed that way.
Tell that to the people writing PS modules. :) Put, Update, Update, Put? PS is a good example of overdesign imho. Also, one can compare for instance Az CLI with Az PS. Takes at least 5 times longer to do anything in Az PS.
`rm -r -fo` will work just fine on powershell, afaik: there is an alias for remove-item called rm, and flags are fuzzy matched. There are two flags starting with f, so fo is needed here, but I don’t think force is that often needed on windows, so in practise it is just as short.
I've run into several compatibility issues because I installed the "new" PowerShell from the windows store, as it constantly nags you to do, and it's not fully compatible with the one that ships with Windows. Just yesterday some chocolatey packages failed to install when chocolatey was invoked from the new PowerShell, but succeeded when chocolatey was invoked from the old one, for some godforsaken reason.
Microsoft should have just adopted an existing shell. They may have problems but the problems are well known and workarounds are well known too. PowerShell is NIH syndrome in action. It has an equally large set of different problems that are unknown. It's a whole new set of quirks and workarounds to learn when you just want to get something simple done.
The only good thing I have to say about it is that it respects my "ls" and Ctrl-R muscle memory.
TBH, I think if the language was done properly, PowerShell would significantly boost Windows' attractiveness to devs and admins, and would probably meaningfully spill over into Linux as well (I'm aware there's a Linux version, but best I can tell nobody uses it if they can avoid it).
Unfortunately the bar set by CMD was far too easy to clear, and Jeffrey created a language that only its mother could love. It does add value, there's no question there, but _in spite_ of the language, not thanks to it. The value add is mostly in bindings.
MS would do well to reuse the same bindings but have Anders Hejlsberg design the language instead IMO.
PowerShell grew up in Windows world, and largely has stayed there. If you are not Windows sysadmin, there is high likelihood you have never ended up on a server with PowerShell installed. I have ~200 server credentials in my password manager, and I can't think any with PowerShell, but maybe over 90% has bash. All the examples for new things usually have just bash instructions.
If I'd give an advice to new programmers right now, I wouldn't say learn PowerShell over Bash, because PS is just so niche.
but powershell is absolutely wonderful if you are running a windows environment.
the fact that it is also able to use aspects of .NET is really, really useful.
I know, I still use Windows for the time being. However there are still cases where it isn't as good as batch programs. Like Windows' task scheduler, you can't add PowerShell script to task scheduler without command prompt appearing [1]
The claim cannot be supported, nor can it be refuted.
Based on your link for public facing servers [1] MS Windows has a Market share of ~22%, which Unix-like operating systems have ~78%. [2] However, there are a lot of operating systems that make up that 78%.
Breaking that down even further Linux based operating systems account for ~49% of that ~78% [3], which means Linux based operating systems have a ~38% total market share compared to Windows market share of ~22%
And again, breaking that down even further Debian has the largest market share at ~35% of all Linux based operating systems. [4] Which means Debian has a total market share of ~13%. Substantially lower than your claim.
In the context of this discussion you can't make the claim that all Linux based operating systems can be lumped together as they all have varying default shells and different versions of shells, so the portability of shell scripts comes into question.
However, beyond this that's only publicly facing systems. There's no way to determine how many installs of each operating system there are in private networks.
Source is the the various articles on the front page of Google. The page you linked refers only to web facing servers, and not any other kind (e.g. databases, VCS hosts, etc.)
PowerShell Core runs everywhere and installing it even on Linux servers now is an easy install away. Sure, no Linux distribution is likely to include it in the base install, but that doesn't necessarily make it niche. "Power user" tools are rarely in the base install and sysadmins have all sorts of install scripts or preferred images beyond just base distributions and few argue many of those "must install" applications were "niche" just because they needed to be installed when setting up a new server.
PowerShell 1.0 saved my bacon in my first job. I was part of an IT consulting firm working for a government agency, and we had no control over the software we installed on our computer (including programming tools). Having a decent scripting language allowed us to create automation tools that made our lives an order of magnitude easier.
I no longer work with PowerShell (or Windows) but I still have fond memories.
I find it quiet funny there are a bunch of unix sysadmins in here talking about how PS isn't great, but admit to only touching it "sometimes" for some minor use case. Well, no shit. I now do cloud/unix/windows dev and formerly used to admin both types and use both bash and PS and have to say I like PS better, only because the community around it is less toxic and does not gatekeep. From actual REPL language POV though, PS serves its purpose quiet well and I look forward to where it takes us in the future.
People that base what tooling they use around how many characters they have to type instead of how productive it makes them seems common but problematic.
> If it take me twice as long to get to the same solution, I'm ultimately less productive.
Exactly, that's why having to guess command/args and google the man-page is way less productive by a lot. For minimal productivity gains in the time it takes you to type a few characters you've wasted minutes.
It shines when you take advantage of it's object model. You are passing around and operating on objects with types, properties, etc. vs. what's effectively glorified string manipulation with bash. That comes with tradeoffs though like the one you mentioned. Memory usage when operating on large datasets is another.
Another big benefit mentioned elsewhere is that you can bring in C# directly into the shell.
In a reasonably modern terminal, tab completion makes it a lot less typing than it appears.
The other thing is that idiomatic PowerShell takes a "Python perspective" that scripts are often read way more often than they are written and the best, idiomatic examples often use the most verbose forms of names to make things clearer to read.
PowerShell has a very rich aliases system with many, much shorter names for almost everything (and the ability to define your own to your heart's desire; and the ability to list which aliases are active on a current system), and you absolutely can code golf PS1 commands down into very bash-like lines. Most PowerShell veterans tend to write extremely terse stuff at the REPL even when in scripts and online documentation they try to stick to the idiomatic verbosity for others that need to read the scripts and understand what they do (even sometimes themselves months or years later).
Seems like you're speaking a different language as someone that's been working in a terminal for almost 20 years. Again, my exposure is to pwsh is very limited, any good examples or comparisons you might suggest?
I'm not quite sure if I'm addressing your question; I am not as familiar with
PowerShell as I am with various unix-like command shells.
But an example that springs to mind for me is "Get-ChildItem".
Two default aliases for this PowerShell command are `ls` and `dir`.
PowerShell seems to build upon data structures, can pass these around much in the same way that is done in the REPL of an interpreter.
Unix shells lean on the file system for that: if you want to "really" pass around data structures, you pass the name of associated file handles, as defined in the namespace of the virtual file system (VFS).
It turn out that the unix way is usually quite sufficient for interactive sessions. Remarkably so.
But I can write PowerShell functions that do type checking. I can sign PowerShell files with a certificate that implements a security policy...
Stuff like that can be done by a Unix shell and VFS in 2021, but the complexity trade-offs start to favor programming environments with a typed call stack.
The top two of majkinetor's list are pretty easy to describe:
PowerShell cmdlets (which is all built-in commands, most first party commands, some second and third party modules and wrappers and anything you can easily do in writing your own functions inside scripts) all share a single argument parser, rather than the usual command line application status quo in other shells where it is every app for itself in argument parsing and some programming languages are better than others at it and some libraries in languages are better than others.
One thing the cmdlet argument parser is good at is that it does make it really easy for the cmdlet author to add aliases (alternate names) for arguments (which PowerShell calls Parameters to the cmdlet) right next to where you define your Parameters. As a comparison, this is equally easy in say Python's argparse where you can provide a list of possible argument names in addition to just a single name. (If you are rolling your own in, say, C it may feel a bit harder.)
The other thing that PowerShell's shared argument parser supports is it always allows you to use the shortest non-ambiguous prefix to name an argument. (This is also something that Python's argparse does by default. Other languages/libraries it varies.) Which is basically that it always supports the "tab completion" automatically without actually having to type tab or "complete" the argument. For instance, the Remove-Item cmdlet often used by the alias `rm` doesn't seem to have any obvious aliases for its parameters, but `-r` works just fine like you would just about expect from other things named `rm` because there is no other parameter that starts R other than "-Recurse". It almost works equally well for Remove-Item's "-Force" parameter with the small hiccup that there is also a "-Filter" so you need `-fo`.
Another thing these last couple things demonstrate is that PowerShell's shared argument parser is case-insensitive. (Python's argparse is not, which is where the shared similarities stop.) PowerShell parameters in documentation are almost always shown in PascalCase for readability but most day-to-day use I see tends to be all lower case just like you just have to do in bash (`rm -r -fo`), only in PowerShell it is an option if you are into brevity rather than the only language that these cmdlets understand/parse.
Having a shared parser for all of this across so much of the shell (and easily used when writing your own functions which are treated as cmdlets just the same) means that you can count on it pretty much everywhere and you don't have to know anything about what language your command line tool was written nor worse what library in that language was used for argument parsing. (Python's argparse was only added to the standard library in Python 3.2! There's still tons of Python command line tools in the wild that don't use argparse at all and manually parse their args or use older libraries with fewer features from before the Python team declared a "winner" and added it to the standard library.)
If you pipe objects around between cmdlets, PowerShell will auto-bind object properties to cmdlet parameters. Which feels like the magic of the Unix pipe text streams everywhere but lets you skip several text parsers (no grep/awk/sed intermediates perhaps) and feels like even more magic when it just works: `Get-Process -Filter something | Stop-Process`. The blog post gets into some of the details of how it works and that it isn't just magic and that in PowerShell you can even inspect with tools like Get-Help to discover how it is doing it and use that to your advantage to automate complex tasks with very simple command lines.
> I find it quiet funny there are a bunch of unix sysadmins in here talking about how PS isn't great, but admit to only touching it "sometimes" for some minor use case. Well, no shit.
So, you want them to use it a lot when they don't like it?
Takes care of the parsing and makes pipelines less brittle for sure (just look at things like NO_COLOR [0] that are basically "please adopt this so we can stop having to add endless edge cases to strip ansi color codes") because it keeps data flowing between programs into a machine-friendly format. It's only when it reaches a human that it is formatted for a human to see.
Then when you peel off the surface you realize you can invoke C# directly from the shell. That's right, either you can import any C# .dll out there and call it from the shell or flat out write C# in your script and have Powershell execute it at runtime [2]. You can add syntaxic sugar to make your dll easier to work with but any C# dll can be called from powershell.
As a side effect, this means that if you have a front-end/back-end app with the back-end written in C#, you also have a (bad) scripting interface basically for free.
I am amazed that there is such misunderstanding of PowerShell.
I partially blame Microsoft because of their idea to aggressively recommend non-aliased PowerShell for EVERYTHING (it backfires entire decade and they still do it, along with the army of "MVP"s, which is amazing head in the sand behavior when entire Internet bitch about it) and because they obviously don't manage user education well.
I then blame everybody else for not RTFM and always complaining about the same nonsense: verbosity, performance, missing short circuit bashizm etc.
Seriously people - PowerShell is one of the best inventions since the first computer that you can use on any OS. If you didn't grok it, its about ====> YOU <==== not about PowerShell.
Once the only real issue is solved (performance is not greatest, but not too bad either), it would border to incompetence to not put it by default on any OS.
Yes. Speaking as someone who has a lot of experience with both (see my github)
- Cross platform
- Extensive Integrations and 3rd party ecosystem
- Generally much shorter code for the same stuff
- Package manager
AHK was never considered a general purpose language nor a good language. I was probably one of the first people to use it that way (See Forms framework). With AHK2 incoming it is much better language (although Lua would be way better instead).
AHK is oriented toward GUI automation, PowerShell toward CLI automation. AHK is not there out of the box on any Windows.
You can basically do anything in anything, but that doesn't mean you should.
its arcane syntax and tendency to behave in unexpected ways is a massive barrier to entry. you spend way too much time trying to figure out the edge cases to command outputs / errors / what-happens-if-the-output-isn't-as-expected (usually due to error conditions.) scripts need to be reliable and predictable (without fuss!) - especially if you're controlling things with them.
I don't much care for the syntax, but I do like having typed data flowing through the pipes. It does take a bit of the busy work out of constantly parsing text data when doing long chain of commands. Everything is text gets tiring sometimes.
Across multiple projects and positions I've used powershell core to normalize all CI scripting across all our native ci/cd tooling.
Its a nice language, with some massively fatal issues, and awkward weirdness that takes me about 10x as long to sort out vs say c++, but its better then bash files on windows (it just doesn't work, really), or bat files on windows etc.
P.S. I'm a cross platform native developer, if windows wasn't in the mix, I'd probably stick to bash
163 comments
[ 2.9 ms ] story [ 193 ms ] threadA lot of Microsoft plugins have PowerShell plugins. This is what makes PowerShell valuable, not some attribute of PowerShell itself.
Really what Microsoft should have done is to make those plugins available to C#. Then make C# usable for scripting purposes -- C# is as easy as most scripting languages in any case, and now with "top-level statements" you don't have to write classes. Make C# usable like Dino for TypeScript (i.e., transparent compilation). Then any syntax errors in the script can be caught ahead of time, instead of after 2 hours of running.
Some of the things are not... ideal. And there's a bunch of legacy stuff in modern powershell that we could do without, but a REPL scripting language with pipe semantics is really useful on a day-to-day basis.
I'm not sure C# would work as a shell language at all.
"It isn't what I'm used to, therefore bad, now let me figure out why." After that the length of commands is an easy target, in particular if you don't know enough about it to criticize it for anything substantive.
Powershell is based on small composable commands that are easy to chain together - as you would know if you've used it at all.
Valid criticisms exist of powershell. It baffles me why Linux refuseniks trot out such easily-discounted objections. My belief is that it's a figleaf over a political position: "I will never use a Microsoft product". We're on HN; that's an acceptable position. Why bullshit?
2) You just keep hitting tab until you get the one you want. This is the tab completion behavior of the Windows command line since it added tab completion.
C) Did I mention it's configurable? https://stackoverflow.com/questions/8264655/how-to-make-powe...
https://github.com/lukeschlather/dotfiles/blob/master/src/Wi...
That said, tab completion works, and I used PowerShell on macOS for a long time with no complaints.
Having Invoke-WebRequest originally use the IE engine for parsing by default was also a terrible idea, but at least they reversed that one.
for scripting I'd personally use neither.
Even without the hyperbole you have a comically exaggerated idea of how long it takes to write quick one-liners in PowerShell. For me personally, it helps a lot that I don't have to look up cryptic three-letter command names, obtuse switches, or the precise sed incantation to glue things together.
- They have a list of standard verbs: https://docs.microsoft.com/en-us/powershell/scripting/develo...
- Every command is verb-noun. So get-[whatever], remove-[whatever], set-[whatever] etc.
Therefore, you can guess get-process would be a command as is stop-process or start-process.
That's not a very high bar to exceed. A glass of water seems like champagne to someone in the desert.
The main reason for this though, is that I can use some familiar Linux commands and I don't need to google how to list files in the current dir (PS and bash both have ls, among others)
Can any scripting language check for that? It is beyond the scope of what an interpreter has available to it.
> PowerShell as a scripting language is a major PITA.
Well, except this part.
> After 2 hours the script would abruptly quit because of some syntax error. 2 hours wasted.
As mentioned by another commenter, the PowerShell script is parsed up front, so it probably wasn't a syntax error. My guess is the script lacked error handling and some query or connection to a remote server failed.
> A lot of Microsoft plugins have PowerShell plugins. This is what makes PowerShell valuable, not some attribute of PowerShell itself.
There we go agreeing again. Although, PowerShell is effectively self-documenting, which is good for busy sysadmins.
> Really what Microsoft should have done is to make those plugins available to C#
A lot of them effectively are available to C#, such as System.DirectoryServices.*. In the early days of Active Directory, before PowerShell, this is how we did things. While fun for us programming nerds, it took a hell of a lot more time to write usable tools.
> C# is as easy as most scripting languages in any case
Hard disagree.
> Make C# usable like Dino for TypeScript (i.e., transparent compilation).
A more C#-like scripting language? I'm all for that, but why not just use TypeScript at that point (ala the JScript days).
> Then any syntax errors in the script can be caught ahead of time, instead of after 2 hours of running.
No, you run into the exact same challenges, whether it's PowerShell or C#.
IMHO, while I'd rather be doing C# programming any day of the week, PowerShell is more approachable for the vast majority of Windows sysadmins out there. Additionally, due to the command... verboseness of PowerShell, it is effectively self-documenting.
Edit: Snover's original Monad Manifesto paper is worth a read for his reasonings about what is now PowerShell: https://www.jsnover.com/Docs/MonadManifesto.pdf
It might be best summarized by this partial quote: "PowerShell replaces fragile, prayer-based text parsing with pipelines of objects (structured data)"
You shouldnt speak down to a whole group of very intelligent people like that.
IE, the vast majority of SYS admins aren't capable of approaching C#. Fully unsubstantiated heresay. If they can learn the cryptic nightmare that is power shell, they can certainly learn C#.
"A lot of sysadmins:
1. Aren't "very intelligent"."
A spade is a spade.
There’s very few times that I need to write a Powershell script that runs like a daemon. I’m typically using it in a notebook in VSCode, but I do* have Kubernetes jobs that are written in Powershell that run periodically. They were quick and effortless to write, run fast (dotnet core,) and are easy for my team to understand if they want to modify them or someone needs to maintain them.
None of my team would willingly learn C#, nor would the business support them writing C#. A powershell script though? Fair game for anyone who wants to look at something new and innovative, it requires nothing if they use ISE, and if they want to, VSCode is already an approved app. Need a hosting platform? You can deploy on Kubernetes if you really want.
It’s a really big barrier to entry to force someone to use C#.
1. Aren't "very intelligent".
2. Aren't smart enough to learn C#, let alone well enough to do systems programming to replace PowerShell.
3. Don't have the time/desire to learn C#, even if they are capable.
4. Don't have the time to write systems management code in C#, as opposed to PowerShell.
Back when I started UNIX system administration, pretty much all sysadmins knew C and could write arbitrary system management utilities in C.
This is no longer the case, for better or worse, the world needs more sysadmins and Microsoft has released server software that can be managed by relatively minimally-skilled people who know how to Google and copy/paste code from websites.
>A lot of them effectively are available to C#
True, though some of them aren't. I ran into one recently...setting the metric value for an ip interface (not a route, an interface). Powershell has that, C# does not, in any way that I can find.
It can be done in C# via WMI (System.Management), but that's a strange old world if you're not used to it. But it's more convenient in Powershell because MS provide modules such as NetTCPIP so you don't need to touch WMI directly.
Oh no it isn't. Very basic stuff like Get-Something piped into a Remove-Something is, but beyond that, it gets complex quick. Add aliases, weird logic and limitations ( do you know you can't break out of a Foreach-Object?), and it quickly becomes an illegible mess that needs parsing, the same way Python might.
Furthermore, a lot depends on the cmdlet provider, and for instance the VMware ones are steaming piles of horseshit with inconsistent naming of parameters, broken async, and useless error management ( e.g. you get an error which says to check the inner exception, but it's empty and there's no way to get any detail whatsoever).
And I say that as someone who really doesn’t like windows (and thinks it is not fit for development at all) — but powershell is really a gem, if one gets over the at first strange syntax and actually looks into it.
I don't because you can.
> Furthermore, a lot depends on the cmdlet provider,
WTF, bash is unusable unless grep, sed, awk and friends are present .
No one is calling bash self documenting, so that comparison doesn't mean anything.
it's not ideal but tapping into the whole system with a coherent syntax / object network is cool and you have blocks / classes to clean up your logic
you can even tap directly into .net (for some reason there's a shortcut to load and compile a god damn source code string)
It seems you're comparing it to ruby or python, am I right ? because IIUC powershell was more a MS OBash for Windows (without bash eternal fingercuts)
https://docs.microsoft.com/en-us/powershell/scripting/develo...
Think of it as the .NET and PS equivalent of a manage.py script.
I agree that PS as a language is quite unusual (e.g. how it returns results) but on the other hand it’s concept of structured data also makes it powerful in ways that old-school Windows scripting or bash are not.
> The provisioning takes 2 to 3 hours. After 2 hours the script would abruptly quit because of some syntax error. 2 hours wasted
Anybody who designed such thing is bad. If stuff fail after 2 hours, you should be able to repeat it in idempotent way to just continue or you skip sections with parameters. Your syntax error problem is the same in any other shell, and in all dynamic languages.
> A lot of Microsoft plugins have PowerShell plugins. This is what makes PowerShell valuable, not some attribute of PowerShell itself.
Nonsense. I almost never use any of the "plugins". PowerShell on its own is game changer. Like the first dude already said, I have yet to see a problem that can't be done in 2-5 lines of code that is joy to read even in shorthand form, unlike countless magic chars, something that is known to be bad pattern in OOP.
> Really what Microsoft should have done is to make those plugins available to C#.
That is really NOT what Microsoft should have done instead of PowerShell, maybe alongside it. But since you have PowerShell, you don't need it that much. Besides, it already exists for almost decade.
> Then any syntax errors in the script can be caught ahead of time, instead of after 2 hours of running.
You can do this today.
I'm not sure if the web could have worked any other way. RPC over HTTP and other message/pub-sub web technologies are largely used by enterprise-level applications, and not by modern web sites, correct?
Here's another example where it's discussing a weakness of MSVC, and every other sentence is just passive aggressively blaming the world for Microsoft's problems: https://devblogs.microsoft.com/oldnewthing/20190830-00/?p=10...
His book, The Old New Thing, is like that throughout.
Yes, but most RESTful apis are backed by an OS that is file oriented. Why? because the server deals with persistence while the API deals with compute. The Windows approach is not winning, hosting APIs on the file oriented OS works better for most. Why? because ultimately APIs are a compute problem not a persistence/storage problem. That said, for interacting with a RESTful api, what tool do you use? A programming language like JavaScript, C#, Python, or Java or a shell scripting language like bash, zsh, or PowerShell?
No? Most RESTful APIs are backed by databases. There's are a lot of variance there (Sql, NoSql, Cloudy Vs. Monothithic) but it isn't files. Even for file storage and delivery databases BLOB storage are often used rather than filesystem files.
When all you're using a filesystem for is storing a large continuous memory-mapped blob so that you can avoid interacting with the filesystem's APIs almost entirely, you aren't exactly championing a filesystem's utility in the internet age.
I'd go as far as to say that directly exposing filesystem files to the outside world is an anti-pattern (because it doesn't scale).
I also think it is disingenuous to talk about HTTP APIs when talking about shell scripting as if it's something that needs to be built into the fabric of the shells design when HTTP APIs can be an abstraction that bolts on top. In fact that's exactly how a lot of CLI tools work (awscli, Terraform, even Powershell scripts will make those API calls in composed functions rather than natively from shell).
It's also worth noting that Linux does have plenty of services that support RPCs too (X11, dbus, etc).
I'm not try to argue that Linux and Windows are equivalent though. Just that it's a little silly to argue that Linux can't do APIs.
CreateProcess is probably my favourite example
NT didn't inherit the problems of fork() with unix, but it's still a disaster of giant nested structures, combined with several different ways of creating lists of parameters (some params need quoting in weird ways, others need manual construction of arrays of null terminated strings)
whereas the POSIX APIs tend to be small, clean and simple
Don’t get me wrong, I really like linux. But I don’t think that posix syscalls are that simple.
"Uniform interface constraint" basically means using very few verbs (GET, POST) on nouns or "files".
This is in contrast to a more highly typed RPC style.
https://stackoverflow.com/questions/25172600/rest-what-exact...
I'd go even further than that and say the web is a straightforward extension of Unix (basically adding URLs, which are amazing, and data driven UI)
... And I'll go even further and say that the Unix-y design CAUSED the success of the web, and if it were more like Windows, it wouldn't have scaled to be truly "world wide" !
The end result is I can't really ever get much done without a lot of googling. But thats par for the course these days I guess.
I know HN is a cloud-first developer community but there is an entire planet of businesses who are software consumers rather than software development firms. Windows is running /a lot/ of stuff even if you personally are not seeing it.
I know a lot of people don't like how verbose cmdlets are, but I find tab completing them to be just as fast and easier to remember than linux's alphabet of case sensitive switches that barely represent the underlying function.
Oh, and keep in mind that we evolved to this from .vbs, which was horrible.
I remember when I was new to shell scripts, thing like basic if loops felt clunky. I would see something like "if [ -r $1 ] && [ -s $1 ]" and not even now where to start. Case statements I could only write by taking an existing one and modifying it.
These days I tend to use Python for all my scripting everywhere I can.
Even within the unix community there are efforts like Elvish and NuShell trying to be more like PowerShell because it's obviously better.
Most Microsoft sysadmins will be living and breathing it.
param statements get you auto-complete, and docs. Powershell can just ingest and deal with JSON, and are one module away from doing the same with YAML.
Using % and ? (aliases for 'Foreach-Object' and 'Where-Object') ends up working very well for most data manipulations that one might be interested in.
It definitely has it's quirks as a language, but so does literally every shell in remotely common use.
And I'd say that Powershell is appropriate for non-trivial scripting use, as long as you familiarize yourself with the conventions for handing data to/from functions vs pipelines.
I've written more than one piece of above ad-hoc software in Powershell, though this is the only one I have in public: https://github.com/yumaikas/psi.
Another thing that bothers me about it is how many Windows system administrators claim they can "script" or "code" because they chain a few cmdlets together.
Seriously, loving the damage control from MS here.
I remember testing out some new languages and toolchains and following the guides, but I would often get many of them that would not work because I was using powershell. Powershell has different syntax for escaping (backtick), starting arrays (parens), etc., that makes many commands completely incompatible (even very short ones).
People feel inconvenienced, which I get, but I feel like people don't give it enough credit for just how well-thought-out the design actually is.
Once you grasp it (which is admittedly easier if you know a Java-like language) your productivity skyrockets as commands are largely guessable and results are largely self-documenting. They have man-pages/get-help, but when an object is self-describing you don't need them as often.
The thing that disappoints me is that nobody from the *NIX world has tried to bring the same ideas there. They're good ideas.
By why does having richer return types necessarily mean you need to deviate from most other languages for the escape character (backtick in Powershell, but usually backslash)? That doesn't seem related, and it greatly impacts the initial impressions people get.
> The thing that disappoints me is that nobody from the *NIX world has tried to bring the same ideas there. They're good ideas.
I agree, and I hope someone does. But if they do, I hope they just focus on the ideas, and leave out the small and unimportant incompatibilities powershell decided to add.
I honestly think someone should do this "from scratch", as you say. I believe the effort would be worth it, but I doubt that the unix community would be amenable to the idea as it goes against their deeply held cultural traditions.
Java borrowed a lot of syntax from C, and it has been very successful. If Java had instead taken the powershell approach of needlessly deviating with the syntax, it probably would not have become as popular as it did. So that example supports the opposite of what you thought it does.
1. https://github.com/xonsh/xonsh
Granted some things are easier done in Linux with a quick bash script. But anything fancy using an sql, api, json and file system I've found ps wins.
But don't get me started with dealing with older versions of PS on production systems.
And to my surprise I found an example and could indeed open the file in the real office powerpoint, export as a pdf file and close it for each one of them with like 8 lines of code. Hell, I could have probably done it in parallel with a single flag (but that didn’t work on my version) In a way, Windows out-UNIXed linux, because contrary to the latter’s philosophy, you don’t really get communication between components because everything is unstructured.
Linux’s analog would be dbus, but that is not integrated with the shell natively.
In your case, the powerpoint program would never be called. You would simply send the powerpoint data to a program that converts powerpoint to maybe postscript, and you would send the postscript to ghostscript to make a PDF.
The unix like a approach is a bit more decoupled.
I cannot think of a single GUI program on linux that works this way (xfig maybe?) but in my mind, this would be the unix way. Of course by the mid 90s, the unix way lost out to the windows way so our GUI world on linux has something of a personality disorder.
I will be hated for this, but systemd would be another good example — you really can’t and should not subdivide such a complex problem into more specific ones. It should be tackled in one place (although systemd is quite modular besides that)
Where is the complexity and overhead? Ppt exports PDF files just fine, would it really be so complicated to move that to an external program?
Powerpoint is made for correctly understanding .ppt(x) files. This complicated functionality should probably not be replicated at other programs as well.
And even GNU/Linux could offer a similar experience if the ecosystem would actually buy into D-BUS or KParts, but that isn't never going to happen, and when only in a specific distribution, with the distribution specific apps, largely ignored by the remaining eco-system.
how is it ad-hoc? this IS the unix interface: command line params mixed with stdin/stdout
instead of DDE/OLE/COM/DCOM/DCOM+/ActiveX/CLR/whatever_it_is_this_week bullshit (mixed in with mountains of crap in the registry)
The reason bash is cool is because i can open it up, and run all these different programs written by different people, in different languages, for different use cases, and they all just work. It's the diversity of the ecosystem that makes the interoperability so cool. If it was all made by a single company, I'd say the usability is a fucking mess.
I agree that doing noun-verb would be easier for autocompletion purposes, but I suspect that ordering was chosen to align more closely with english grammar, specifically https://en.wikipedia.org/wiki/Subject%E2%80%93verb%E2%80%93o...
>Finally, options are also too long. Compare `rm -rf` with `Remove-Item -Recurse -Force`. Capitals, dashes, long words... It's too much!
but they're far more readable. You might be able to remember what -rf does for rm, but what does -o mean for curl? What's the difference between -o (lower case) and -O (upper case)?
Complaining about long capitalized names with dashes in them is a little weird in a language that is both case-insensitive and has tab complete for everything though.
Possibly a good idea on paper. In practice, at least as an only occasional PS hacker, it always eats up a couple brain cycles.
https://docs.microsoft.com/en-us/powershell/scripting/develo...
Microsoft should have just adopted an existing shell. They may have problems but the problems are well known and workarounds are well known too. PowerShell is NIH syndrome in action. It has an equally large set of different problems that are unknown. It's a whole new set of quirks and workarounds to learn when you just want to get something simple done.
The only good thing I have to say about it is that it respects my "ls" and Ctrl-R muscle memory.
https://www.dreamtruegroup.com/aluminum-tank-trailer/
Unfortunately the bar set by CMD was far too easy to clear, and Jeffrey created a language that only its mother could love. It does add value, there's no question there, but _in spite_ of the language, not thanks to it. The value add is mostly in bindings.
MS would do well to reuse the same bindings but have Anders Hejlsberg design the language instead IMO.
If I'd give an advice to new programmers right now, I wouldn't say learn PowerShell over Bash, because PS is just so niche.
[1]: https://github.com/PowerShell/PowerShell/issues/3028
Source? Seems to contradict this page. https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...
Based on your link for public facing servers [1] MS Windows has a Market share of ~22%, which Unix-like operating systems have ~78%. [2] However, there are a lot of operating systems that make up that 78%.
Breaking that down even further Linux based operating systems account for ~49% of that ~78% [3], which means Linux based operating systems have a ~38% total market share compared to Windows market share of ~22%
And again, breaking that down even further Debian has the largest market share at ~35% of all Linux based operating systems. [4] Which means Debian has a total market share of ~13%. Substantially lower than your claim.
In the context of this discussion you can't make the claim that all Linux based operating systems can be lumped together as they all have varying default shells and different versions of shells, so the portability of shell scripts comes into question.
However, beyond this that's only publicly facing systems. There's no way to determine how many installs of each operating system there are in private networks.
Long story short, it's a silly thing to debate.
[1] https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...
[2] https://w3techs.com/technologies/overview/operating_system
[3] https://w3techs.com/technologies/details/os-unix
[4] https://w3techs.com/technologies/details/os-linux
I no longer work with PowerShell (or Windows) but I still have fond memories.
Until then, the footprint is too big, and the installed base is too small.
Microsoft itself is responsible for the POSIX shell - it was required to compile into a 64k text segment on Microsoft Xenix.
Without Bill's beloved Xenix, ksh88 would have been the POSIX standard.
It's all Microsoft's fault.
I simply cannot relate to this prioritization.
Exactly, that's why having to guess command/args and google the man-page is way less productive by a lot. For minimal productivity gains in the time it takes you to type a few characters you've wasted minutes.
Another big benefit mentioned elsewhere is that you can bring in C# directly into the shell.
The other thing is that idiomatic PowerShell takes a "Python perspective" that scripts are often read way more often than they are written and the best, idiomatic examples often use the most verbose forms of names to make things clearer to read.
PowerShell has a very rich aliases system with many, much shorter names for almost everything (and the ability to define your own to your heart's desire; and the ability to list which aliases are active on a current system), and you absolutely can code golf PS1 commands down into very bash-like lines. Most PowerShell veterans tend to write extremely terse stuff at the REPL even when in scripts and online documentation they try to stick to the idiomatic verbosity for others that need to read the scripts and understand what they do (even sometimes themselves months or years later).
Not only use of cmdlet aliases make shorter syntax but also:
- Shortening parameter names to unique prefix
- Use of parameter aliases
- Use of automatic pipeline property binder
In my experience achieving the same or shorter one-liners for the same task as with bash is typical.
But an example that springs to mind for me is "Get-ChildItem".
Two default aliases for this PowerShell command are `ls` and `dir`.
PowerShell seems to build upon data structures, can pass these around much in the same way that is done in the REPL of an interpreter.
Unix shells lean on the file system for that: if you want to "really" pass around data structures, you pass the name of associated file handles, as defined in the namespace of the virtual file system (VFS).
It turn out that the unix way is usually quite sufficient for interactive sessions. Remarkably so.
But I can write PowerShell functions that do type checking. I can sign PowerShell files with a certificate that implements a security policy...
Stuff like that can be done by a Unix shell and VFS in 2021, but the complexity trade-offs start to favor programming environments with a typed call stack.
PowerShell cmdlets (which is all built-in commands, most first party commands, some second and third party modules and wrappers and anything you can easily do in writing your own functions inside scripts) all share a single argument parser, rather than the usual command line application status quo in other shells where it is every app for itself in argument parsing and some programming languages are better than others at it and some libraries in languages are better than others.
One thing the cmdlet argument parser is good at is that it does make it really easy for the cmdlet author to add aliases (alternate names) for arguments (which PowerShell calls Parameters to the cmdlet) right next to where you define your Parameters. As a comparison, this is equally easy in say Python's argparse where you can provide a list of possible argument names in addition to just a single name. (If you are rolling your own in, say, C it may feel a bit harder.)
The other thing that PowerShell's shared argument parser supports is it always allows you to use the shortest non-ambiguous prefix to name an argument. (This is also something that Python's argparse does by default. Other languages/libraries it varies.) Which is basically that it always supports the "tab completion" automatically without actually having to type tab or "complete" the argument. For instance, the Remove-Item cmdlet often used by the alias `rm` doesn't seem to have any obvious aliases for its parameters, but `-r` works just fine like you would just about expect from other things named `rm` because there is no other parameter that starts R other than "-Recurse". It almost works equally well for Remove-Item's "-Force" parameter with the small hiccup that there is also a "-Filter" so you need `-fo`.
Another thing these last couple things demonstrate is that PowerShell's shared argument parser is case-insensitive. (Python's argparse is not, which is where the shared similarities stop.) PowerShell parameters in documentation are almost always shown in PascalCase for readability but most day-to-day use I see tends to be all lower case just like you just have to do in bash (`rm -r -fo`), only in PowerShell it is an option if you are into brevity rather than the only language that these cmdlets understand/parse.
Having a shared parser for all of this across so much of the shell (and easily used when writing your own functions which are treated as cmdlets just the same) means that you can count on it pretty much everywhere and you don't have to know anything about what language your command line tool was written nor worse what library in that language was used for argument parsing. (Python's argparse was only added to the standard library in Python 3.2! There's still tons of Python command line tools in the wild that don't use argparse at all and manually parse their args or use older libraries with fewer features from before the Python team declared a "winner" and added it to the standard library.)
https://devblogs.microsoft.com/scripting/learn-about-using-p...
If you pipe objects around between cmdlets, PowerShell will auto-bind object properties to cmdlet parameters. Which feels like the magic of the Unix pipe text streams everywhere but lets you skip several text parsers (no grep/awk/sed intermediates perhaps) and feels like even more magic when it just works: `Get-Process -Filter something | Stop-Process`. The blog post gets into some of the details of how it works and that it isn't just magic and that in PowerShell you can even inspect with tools like Get-Help to discover how it is doing it and use that to your advantage to automate complex tasks with very simple command lines.
So, you want them to use it a lot when they don't like it?
Takes care of the parsing and makes pipelines less brittle for sure (just look at things like NO_COLOR [0] that are basically "please adopt this so we can stop having to add endless edge cases to strip ansi color codes") because it keeps data flowing between programs into a machine-friendly format. It's only when it reaches a human that it is formatted for a human to see.
Then when you peel off the surface you realize you can invoke C# directly from the shell. That's right, either you can import any C# .dll out there and call it from the shell or flat out write C# in your script and have Powershell execute it at runtime [2]. You can add syntaxic sugar to make your dll easier to work with but any C# dll can be called from powershell.
As a side effect, this means that if you have a front-end/back-end app with the back-end written in C#, you also have a (bad) scripting interface basically for free.
[0] https://no-color.org/
[2] https://tekcookie.com/use-c-in-powershell/
I partially blame Microsoft because of their idea to aggressively recommend non-aliased PowerShell for EVERYTHING (it backfires entire decade and they still do it, along with the army of "MVP"s, which is amazing head in the sand behavior when entire Internet bitch about it) and because they obviously don't manage user education well.
I then blame everybody else for not RTFM and always complaining about the same nonsense: verbosity, performance, missing short circuit bashizm etc.
Seriously people - PowerShell is one of the best inventions since the first computer that you can use on any OS. If you didn't grok it, its about ====> YOU <==== not about PowerShell.
Once the only real issue is solved (performance is not greatest, but not too bad either), it would border to incompetence to not put it by default on any OS.
- Cross platform
- Extensive Integrations and 3rd party ecosystem
- Generally much shorter code for the same stuff
- Package manager
AHK was never considered a general purpose language nor a good language. I was probably one of the first people to use it that way (See Forms framework). With AHK2 incoming it is much better language (although Lua would be way better instead).
AHK is oriented toward GUI automation, PowerShell toward CLI automation. AHK is not there out of the box on any Windows.
You can basically do anything in anything, but that doesn't mean you should.
https://github.com/majkinetor/mm-autohotkey
Its a nice language, with some massively fatal issues, and awkward weirdness that takes me about 10x as long to sort out vs say c++, but its better then bash files on windows (it just doesn't work, really), or bat files on windows etc.
P.S. I'm a cross platform native developer, if windows wasn't in the mix, I'd probably stick to bash
He covers almost every point discussed here and then some.
Fascinating read, way more interesting than the small religious squabble here.