I loved powershell with (some of) its weird warts, but I have moved on.
Say what you want about bash, at least it doesn't pull stunts like that.
https://flowingdata.com/2011/06/30/organizational-charts-in-...
(hey, I managed to sneak a rifle past HN's Unicode filter :-D)
It is as if DevDiv is now full into UNIX like, poliglot, FOSS culture and such, now under Azure business unit, whereas WinDev is back into how to sneak people into Windows licensing and the usual old culture.
> Say what you want about bash, at least it doesn’t pull stunts pile that.
I guess it depends on what you consider to be included in the terminal’s domain? There are entire papers and guides on which commands are considered safe (sometimes only when run in a very specific way), and which variants, alternatives, etc. you should use instead, for Bash scripts, because of the inconsistency in what a command evaluates, does, and returns for various distros. That’s not to hate on Bash, but just to point out that it’s not a strength of Bash vs PS.
Or the Powershell way where on can access data members directly.
I thought I would prefer the second method more, because the access looked much cleaner/structured.
But after all these years (still mostly Unix scripting but Powershell and some other environments too) my mind has changed.
Would like to hear what others would prefer' Unix method with some scripting language or windows method with Powershell)
And this is exactly the problem.
You no longer have en_US as a locale? Have some titles lounger.
You no longer have en locale at all? Have an greška instead of error.
Oh, you the schmuk who don't agrees to use the best units in the world, totally retarded and "bUt iF yoU WriTe THe dATe as in the journal..."[0] but freedom ones? No longer accept 13 as an hour. Like come on, every idiot knows there is no such thing as an 13th hour!
Oh, you added an additional column to help your busniessor whatever? Your sEd MagIK gone to hell.
Should I continue?
[0] when was the last time you actually wrote multiple documents so you can actually benefit from MMM-dd?
I'm not aware of any difference in bash between vendor distributions for which this is true.
In the past I've seen bad things happen because a script was written by someone on OSX that gets run on a Linux (GNU) based system.
Two common examples are the `sleep` and `sed` commands.
Edit: I meant to reply to the parent comment.
Monopolies always destroy innovation.
gcm | ? noun -like winget*
help Install-WinGetPackage
For instance https://github.com/microsoft/winget-cli/issues/3820 or https://github.com/microsoft/winget-cli/issues/3231.
Also, even though it does not completely work with PowerShell 5, it is marked as compatible. https://github.com/microsoft/winget-cli/issues/2881
The design choices made makes it weird. I hope it would be a good one in the future. But it is now problematic.
Install-Module -Name Microsoft.WinGet.ClientYes what I am doing can be done with intune but that's another story for another time. RIP Store for Business. I just want to deploy PowerBI and have it always be current and self updating.
I primarily write Powershell Core scripts for scenarios where I need to execute the same commands on a variety of operating systems, and I know that the script is likely to be maintained by your “typical” sysadmin (highly technical, but not a programmer)in an environment where installing runtimes for programming languages is discouraged. I switched to macOS as my daily driver about 2 years ago, so PS fits these scenarios pretty well, and Powershell Core updated fairly regularly. Sure there are annoying bugs and misses with the built-in and add-on MS modules: networking cmdlets are an almost total miss, Get-LocalGroup (and maybe other commands?) is totally broken on some AzureAD-joined machines, and the Azure and MgGraph Powershell modules still don’t have enough coverage to move on from the legacy Windows Powershell modules (or even to rely on just one of them, for areas they supposedly cover). But overall I’ve been pretty happy that 99% of the time I can write a powershell script once, and it will run on any machine with Powershell Core, in a consistent way.
There's still a lot of good stuff wrt powershell maintainability by normal humans (though the entire mental model of object output usually throws them for a loop for years) managing local stuff.
If you have a background in windows dev or any of those tools then yeah, easy mode go grab your tools, but for most people doing system automation the calling conventions and complete lack of discoverability within the powershell ecosystem (and their tools in no way helping out) made this not a realistic use case.
Shoot I have seen some powershell modules that have to embed string C#s and eval thing just to have basic performance or other basic use cases.
From the perspective of the Lisp Machine or, hell, even the AS/400, PowerShell (and, while we're here, the CLR) doesn't quite go deeply enough, pervasively enough, across the system to make it truly useful in the same way.
At the very least they could have helped with the discovery/usage problem, but that would probably have been a really tall order for one little language to do.
import xmlrpc
svr = xmlrpc.connect('http://remote/')
result = svr.add(1, 2)
In any decision, Python goes for "What would Guido do?" and C# gets some union of "what would a committee of Microsoft, IBM, Oracle do?", "What would impress Gartner?", "What is Microsoft legally obliged to do, and backwards-compatibly required to do?", "What would we do if we tried to do everything everyone needs all in one?", "What would Java do?", "What would a large team need to design and maintain a stable, typed, large system for years?".
PowerShell is on top of that; there's no simple included graphing and drawing, no simple hooks into Windows own voice recognition and OCR, and definitely not into whatever magically good ones newer Office / Cloud is using, no casual email or spreadsheet handling, no Visual Basic style form building, no simple data science; there's a few things you can do or download, generally less convenient than a Python equivalent. And Microsoft are leaving it all 'to the community' but the community is using Python so that's where the Excel power-user who wants to script a couple of things will go.
I have never desired to do xmlrpc, ocr, voice recognition, or gui building from my shell (and if I did I still don’t see how importing a C# library would be a big miss). What I do desire to do is open files, read their contents and pipe them into other programs, something that Python makes a pain to do with all the file handling. Powershell definitely excels at this, does that make Python a big miss?
in that context C# library isn't fit for it. Yes I agree Python and PowerShell aren't going for the same things; that's annoying because PowerShell is 80% of the way there.
> "I have never desired to do ocr, voice recognition, or gui building from my shell"
I have wanted those things. Windows which has a built in speech recognition engine which is COM automatable, a shell (PowerShell) which can be a COM client, and I have a folder full of phonecall recordings. I have a folder full of photos with things like menus and road signs and I want the equivalent of strings.exe for OCR and PowerShell could almost do it. I've wanted to build a Delphi or VB6 or C# style drag-drop GUI and tried to do it in PowerShell with SharpDevelop, WinForms code, the ShowUI module. I've wanted to build a TUI but Windows console host isn't good at those. I've wanted to get jpg metadata out and done it with Shell.Application automation around Explorer instead of downloading mediainfo.
All these thing have something in common - a core in a low level language, glued together or scripted in a high level language. Microsoft have written the core. They have written the high level language. They just didn't bother to make it all integrated for the ordinary power user, or flesh it out with more features along those lines over the years.
> "if I did I still don’t see how importing a C# library would be a big miss"
Because, compared to a builtin "ConvertFrom-Speech" you have to be enough of a programmer to know you need C#, go looking for a package, navigate oneget/winget/psget/nuget/github to download it, worry about .NET version compatibility and module paths, work out how to add an assembly, and then deal with interop, [ref] parameters, byte arrays, streaming.
> "What I do desire to do is open files, read their contents"
Same. And the contents could be all common formats on Windows since the 1990s - MP3, JPG, Excel - things Windows can read and play, things Explorer can read metadata from.
> "and pipe them into other programs, something that Python makes a pain to do with all the file handling. Powershell definitely excels at this, does that make Python a big miss?"
Yes, I think PowerShell is a far more convenient REPL than Python's REPL. Than any REPL I know of, actually - within the boundaries of introspecting small simple data, PowerShell and .NET at least. And yet Python has set()-set() and PowerShell has [system.collections.generic.hashset[psobject]]::new().ExceptWith() (it doesn't return anything it mutates in-place) and every week, people post on the internet asking how to do essentially set union, intersection, subtraction and equality checks in PowerShell and the answer has been unsatisfying for decades.
Worrying about version compatibility for new projects has stopped being an issue. The package either targets NS2.0 or whatever latest LTS currently is, in which case you just add its reference, or it doesn't in which case you use something else.
If it does, in 98% situations it just works. In the last 2% it has native dependencies which means either a) the package ships with binaries built for all popular platforms, b) the package adds a platform-specific dependent package automatically, or manually and mentions that in README (either with dotnet add package or system-wide library, apt-get install and friends), or c) the package comes with windows only native dll, which happens with ancient unmaintained packages, it's a rare case nowadays fortunately.
As someone whose primary PL is C#, I found https://github.com/waf/CSharpRepl and https://github.com/dotnet-script/dotnet-script far more accessible and useful. Compilation caching for the latter works relatively well to make startup latency tolerable for using it for writing scripts over Python. It's not the smoothest ride, but the advantages of C# make up for this.
Or I just do `dotnet new console -o MyScriptName --aot`, echo code into Program.cs and `dotnet publish -o .` it. Some do that with Rust as well. Especially useful if you need your script to go through a lot of data quickly and parallelize that well too.
"It would be nice if Microsoft polished the stuff they already ship so non-programmers could use it more easily"
"Well I'm a professional programmer (and I have installed a bunch of SDKs and tooling already) and I find all this trivial".
(and it was not that different from the UX above anyway, way better than e.g. Python)
But PS Core is a programming language, right? And only installed by default on Windows?
I'm assuming there's other constraints on your system that make it preferable to installing bash or python on your Windows boxes?
(There’s also the Az CLI tool, which I don’t like as much as the Az PowerShell module but might be easier to manage in an environment like that.)
You have Azure Powershel Cmdlets (the old 5.1 based, and the new Powershell Core based), AZ CLI (in Python), AZD CLI (in Go).
The only one that offers full power is actually the AZ CLI one, e.g. some Kubernetes features aren't exposed in the others.
[0] https://learn.microsoft.com/en-us/cli/azure/what-is-azure-cl...