I'll admit to being in the "Bash is what I know, I'll just install WSL/Cygwin/PuTTY on my Windows workstation and be done with it" crowd. PowerShell is on my bucket list of things I need to learn at some point, or at the very least just get a RosettaCode cheatsheet of common stuff I do in bash and how to do it in PowerShell for when I'm stuck on remote Windows servers.
The costs of doing this don't get enough mention though. You're essentially locking yourself into an ecosystem.
It's typical in bash to have a pipeline where every program is written in a different language -- shell scripts, Python, C, C++, Rust etc. They can all operate on text, but what is a Python program supposed to do with a Rust object or vice versa?
It only works between two programs that support the same object format. But in that case you're effectively passing an object to a function in the same language. Languages already have that with lower overhead than pipes. Even if you're set on using pipes, nothing really stops you from piping a binary format object from one program to another, as long as they use the same object format.
So I think the people who say to compare PS to python and not bash are right, but it's not even that -- just compare it to any other language that has objects. It can pass the objects easily within the language but not outside of it. That's hardly a novelty. And then, despite the ostensible ports to other platforms, you have the usual drawbacks of vendor-specific languages -- many of the APIs only exist or do something useful on Windows and you're locking yourself into the platform.
This would make it possible for PowerShell to interoperate with other command line facilities.
Prior to this I had never really explored PS, but it is definitely cool
Shameless Plug:
You'll notice that the PowerShell and Python versions are very similar.
I really dislike those comparisons where one side wins not because the language is better, but because it does much less.
I use Bash for all my scripting needs, on both Windows and Linux - I just can't get over my dislike of Powershell's verbose syntax and Pascal-Snake-Case naming!
But some things are difficult or finicky in Bash; maybe I should stop putting off learning Python...
PowerShell occupies the same area on Windows that REXX did on OS/2, indeed the same area that Object REXX did. Its useful properties are not that it can be made to look somewhat like POSIX shell commands. In many ways asking "What are the advantages over a POSIX shell?" is not even asking the right question. Its useful properties are rather different.
One such is that it can be used as an interpreted environment for rapidly prototyping .NET programs. I've used it to interactively do quick and dirty mixed file and SQL handling that would have required several full edit+compile+debug cycles in C# (and not just edit-and-continue).
It can speak to anything that has a .NET API. This includes Windows Forms. https://github.com/jdebp/terminal-tests/blob/master/PowerShe... is a PowerShell program that uses ECMA-48 output to Windows Terminal to draw a wriggling worm, with a Windows Forms dialogue box alongside it that can control various test parameters as it goes.
It's employable in the same sort of "glue" areas that REXX was. It is very useful in Azure/TFS build pipelines, for example. Don't think of it as a "server" thing because of this, though. It's a "glue" thing, as useful on desktop machines as on servers. It's the same improvement over writing glue as CMD scripts on Windows as REXX was over writing glue as CMD scripts on OS/2.
I haven't explored its embeddability myself, but like TCL, REXX, and others it can be used as an embedded in-process scripting language within other programs. Again, this isn't something that one directly contrasts with a POSIX shell.
That being said, I still feel violated every time `ls` returns `bad command or filename`
The only things I found worse:
1 - error handling doesnt bubble in the same way. e.g. I can't do an equivalent of `set -e`, or do `cmd && other_cmd`
2 - return values are very nuanced. If you don't understand how function statement contribute to the result, you will spend a lot of time debugging odd issues
At the top of the script is the closest I fount to `set -e`
It does, called OneGet and recently rewritten.
You can also use chocolatey.
For windows update: https://www.powershellgallery.com/packages/PSWindowsUpdate/2...
There’s also a lot of just straight errors, such as mentioning “true” and “false” “values” in Bash, which don’t exist—the userland toolset includes “true” and “false” programs that can be used to inject desired exit code status into some logic flow, but there is no real concept of a Boolean type.
Overall, if you’re going to provide a rundown of how x and y compare, you should probably give real examples, not just a laundry list of “instead of grep, we use select-string; instead of sed we use -replace”. But how do you use them? I worked with Powershell some over a decade ago, but this article doesn’t give enough info for me to understand what to do with the information it’s providing. And given the errors in describing how Bash works, I’m skeptical that the Powershell examples are syntactically correct either.
I have just seen scroll size and imediatelly closed it.
Besides, Powershell comes with OS.
The selling point of ps is the piping of objects. Mac and linux api don't output those.
The second biggest issue I've seen is generic lack of robustness and maturity. Default cmdlets do the common case nicely, but once you have something unusual in the mix things go wrong fast... By unusual, I mean things like filesystem junctions, volumes mounted into directories.
If you want colors, Write-Host is nice. Except that it goes only to console AND to (undocumented?) file id 6! (same way like stdout goes to 1, stderr to 2, etc.).
PowerShell seems to behave slightly differently in each Windows version. A script that's written for Win10 1803 might just break under 1809.
I don't have much issues with Bash etc., even sh. It performs well and is very robust. I do hate its many footguns, like how easy it is to get escaping wrong.
Get-Help about_Redirection
Yeah, totally got that. But how else you can generate colorized easy-to-read output, where yellow warnings stand out?
There should be something like Write-Host that outputs colors to console stdout handle and silently drops color properties when writing to (anonymous) pipe stdout handle.
Color escape codes could be even better.
edit: "if" example also misses a semicolon before "then".
Known Issues for PowerShell on Non-Windows Platforms
https://docs.microsoft.com/en-us/powershell/scripting/whats-...
Once you learn it, you know about them.
It is recommended that you use full names in scripts for readability reasons so most script examples on the web have those long obnoxious names.
Also, tab completion works really well with command argument names so in practice it's not that many keystrokes.
The problem with pipelines of objects is that it is inherently a more strongly typed, defined, interface. And therefore special-case. Streams of characters is as loosely typed as it gets. And for processing text files and gluing disjointed tools together, it may seem crude, but is very effective. Especially for quick text processing jobs, or automating series of commands.
The UNIX shell concept has been honed and refined over 50 years to do exactly what it does, and it does it very well. It is also extremely generic. This choice was on purpose and has stood up well to the test of time.
Powershell is somewhat a perl-for-windows-admins. A write only pile of special tools and special cases for the peculiarly baroque system interfaces of that particular OS. Neither better or worse than VBA from what I can tell, just the passing style this decade.
Not true. While I am somewhat of a novice at powershell, I didn't find that to be the case at all.
> Streams of characters is as loosely typed as it gets. And for processing text files and gluing disjointed tools together, it may seem crude, but is very effective. Especially for quick text processing jobs, or automating series of commands.
Well done for the Pavlovian regurgitation of how piping text output is supposed to work.
I don't like working with it. It is okay for small scripts. However if it is mildly complicated I would use something like Python (not powershell).
Powershell is great for small scripts where you need to do sysadmin tasks e.g. I have a script where I setup my SQL Database aliases for development. Piping text about doesn't help me in these sorts of tasks. I need to go "I need to find where the real database is, and then map those properties to an alias". That works better with piping objects. It works kinda like functional concepts such as map(), reduce() etc.
You should use the right tool for the right job.
> The UNIX shell concept has been honed and refined over 50 years to do exactly what it does, and it does it very well. It is also extremely generic. This choice was on purpose and has stood up well to the test of time.
You know not everyone thinks that Unix was the pinnacle of human achievement.
Why isn't this false? Is it doing type checking instead of a value comparison?
To be more evil, your text parsing wont work on all platforms, and you probably didn't od it right or you need to be Reg Exp master which is something I rarely find even in senior devs.