No sarcasm you say
Phooey El Reg, this software ran on my server and turned me into a newt.
Er..well, ... I got better!
Microsoft on Thursday released a preview version of PowerShell 7, its command-line shell and scripting language for administrators. The software was once was limited to Windows but opened up to Linux (including arm64) and macOS three years ago. Steve Lee, principal software engineering manager, announced the software's …
I got some sarcasm:
a) part of the Embrace, Extend, Extinguish plans for Linux
b) but it is STILL ".Net"ty
c) it's for alleged programmers that don't know how to use bash and Perl
d) Have they never heard of 'Python' ?
e) I can do more with less in shell/Perl and either Cygwin or Linux
f) from the same kind of crowd that LOVES systemd...
should be enough for now.
icon, because, facepalm
"Perl is a fully featured programming language, powerscript isn't"
Oh yes it is in a similar way that Perl is.
"Its a scripting language designed to control Windows objects and processes."
Perl is primarily a scripting language too. Powershell is cross platform and doesn't just work on Windows. For instance WS-Management and CIM enables management of remote Linux systems and network devices. PowerShell also provides a hosting API with which the PowerShell runtime can be embedded inside other applications including those exposed via a GUI
Wow, remote management, cutting edge stuff.
So - for example - how exactly would you write a multiprocess TCP networked middleware layer using a proprietary binary protocol on the front end and talking to a DB on the backend in powershell then? Because I've seen that written in Perl.
Take your time.
Addendum: I was just reading below and I can see the comments on "my team" are not very good - I'm not with those guys! Take this at face value.
Like the emperor in Star Wars "I shall become more powerful than you can imagine" or something? It's very hard to measure this (beyond the 4 levels of computational power ending with "turing machine") and I'm not sure "oh yeah in this language you can just type the letter z and I made it do that exact thing for you" is good - as that'd make whatever the fuck it is "more powerful" right?
However I'm very sceptical that PowerShell is something that what 50 years of shell developers thought "you know what we don't need" and it isn't a case of "we do it how we've always done it" (look at pipes, albeit an old example).
Having said that I don't really care, I hear that it's got a notion of types so you can stick JSON between things, and I've not bothered to look it up to see if this is true. It didn't stop me shaking my head and sighing - thinking "when will they learn" to myself. I could write (so trivially that it's not worth checking for existing work from, considering only time and effort) JSON stuff to extract, append, ect ("" XML with XPATH) - I could also write that parallel for thing mentioned as a program which takes as arguments what to run without touching the shell, just as it is possible (modulo low hanging fruit for error messages and general speed improvements) to do with arithmetic
Seriously it'd be easy. Easier than faffing around with job control ;)
I think we should measure power as "A is at least as powerful than B <--> for all things B can do A can do it too" (said differently, B is no more powerful than A) - without invoking Turing! I could work in XML if I wanted to. I could not use anything on the normal PATH and use some other stuff instead....
I've admitted I'm not fit to compare the two, but is there even a point to trying? What I've described is (mostly? Dare I say all?) vanilla POSIX shell stuff!
I think the reason they only allow tricks on powershell commandlets to make your email work is so you order a hosted solution such as outlook365. It's complicated -perl or bash is like basic compared to powershell-, slow and full of undocumented 'features' you only learn about after paying a consultancy that regularly swipes the credit card with MS.
As an occasional Perlmonger (and huge perl fan) and regular PoSH scripter, I have to say this is disappointing. Once upon a time it was Microsoft that spread blatant FUD about Open Source software. Now it's a certain variety of Linux fanboy who spreads FUD about Open Source software.
"I think the reason they only allow tricks to make your email work on powershell commandlets is so you order a hosted solution such as outlook365."
There is no Microsoft product called outlook365. If you meant Office 365, the things you can only do in Exchange on-premises with Powershell are also the things you can generally only do with Powershell in Office 365.
"It's really complicated - perl or bash is like basic compared to powershell"
I think real afficionados of perl and bash would be offended at a comparison to basic. But sure, let's play the complexity game:
A simple Perl echo without resorting to wrapping externally utilities or modules:
open (FILE, '<', "complicated.txt");
[root@shell ~]# ./echostuff.pl
Why do you have to go and make things so complicated?
I see the way you're acting like you're somebody else gets me frustrated
PS D:\OneDrive\Documents> gc .\abc.txt
I'm gonna teach you
How to sing it out
Sing it out, sing it out
Sing it, sing it
A B C it's easy
It's like counting up to 3
"slow and full of undocumented 'features"
You... do know it's Open Source right? Here's the landing page for Powershell 7's github repository, and also the very, very extensive documentation, above and beyond that included with cmdlets and updated in-environment using the update-help cmdlet
"you only learn about after paying a consultancy that regularly swipes the credit card with MS."
So... you or your employer paid someone for expertise in a programming language you had no resource in? How is this different from every single other programming language, or IT discipline?
you forget the WORST part: the ".Net" integration.
what MS did with ".Net" in teh early 2000's is why I hate it, why I hate C-pound, why I _refuse_ to allow my C++ programs to have bindings with ".Net", and so on.
Using Power[S]Hell (for other than 'occasional things') is something I won't be doing any time soon, ESPECIALLY on a non-windows system. And I've looked at it, and even tried invoking 'special things' from it [on recommendation on various web 'how to make this happen' pages, particularly enabling unsigned drivers to load and things like that]. The documentation is VERY hard to find things in, as it's poorly organized, but I have that criticism for MSDN in general, latly. It used to be better when there was a local help application and you could ONLY load the relevant help files, and NOT every-freaking-thing-in-the-world so that you could SIGNIFICANTLY narrow down your searches by NOT having the entire universe...
so yeah this is part of some general criticism about MS these days, and Power[S]Hell is just a part of it.
(/me back to bash and occasional Perl, and if they won't do it, simple C language utilities to make up the difference)
"The documentation is VERY hard to find things in"
Every single command has a page which lists the syntax, all the possible parameters, helpful examples etc. (eg)
If you find that hard, (sorry, "VERY hard") then I struggle to think what your idea of easy is. Large pictures and no words longer than two syllables perhaps? Or perhaps pages made of cardboard and a waterproof cover?
... which is great and complete and thorough.. and utterly useless if *you don't already know which command you need*. Given that powershell command names bear no relation to the commonly-used commands in other languages, most people will stick to other languages where the entry barrier is lower.
I use it on occasion, for things I can't do any other way, but I'd still prefer not to.
Most of the time Powershell scripts to work invoke several C/C++ APIs, usually using some flavour of COM or Win32 - which is the reason why they are often far slower than invoking those same APIs directly from compiled code.
That's why all Windows administration tools became a pain in the ass to work with, being slow to start, slow to use, and with bad error reporting.
Exchange 2007 started it actually, not 2010*, although with Exchange 2010, you could see what PowerShell code is about to be called from the GUI.
One of the things that made pre-SP1 Exchange 2007 a steep learning curve for admins was a lack of capability in the Exchange Console (GUI) because Microsoft effectively rushed the release of Exchange '07 to hit their release target.
Most simple tasks (simple in the GUI) required quite complex PowerShell.
Also PowerShell came from the previously named product "Monad"
*It is entirely possible other products shipped with it first, but my own memory says it was exchange 2007.
And it turned it into a nightmare. The GUI launches a powershell script that has far worse error handling than the GUI calling APIs itself - and if something doesn't go well it has to desperately parse the script output letting the user decipher what went wrong. It become also far, far slower as the .NET overhead it's still very present regardless what MS could say, especially when the script has to call native C/C++ code continuosly to perform any useful task.
Don't get me wrong if both the GUI and the script called the same API, it was just a matter to select what tool was better for a given need. But having the GUI calling a script instead of an API is truly an idiotic design.
"There's a bunch of stuff that you can only with the Exchange powershell commandlets."
Just because the API aren't surfaced in the GUI - as MS made GUI development even slower than it was with .NET -, and not documented. Exchange is not a .NET application.
I installed a recent build of Windows 10 on a vm to test some software. This is all offline without any updates, DRM activation etc. I opened up powershell and was greeted with a message to try out a newer version of powershell...
... I hate this kind of begger-ware.
If I want to try something, I will. Until then, please reduce the amount of visual overload I am starting to see more and more in such a sodding consumer platform.
It’s quite weird, one of the MS things that is actually quite good.
The boot on the other foot.
I think Jeffrey Snover poached developers from the UNIX world to create it. They based it on Korn Shell grammar.
Snover claimed unix scripting tools wouldn’t work well with windows, yet years later they are in Windows.
why not just write a simple C or C++ application to access the Win32 API and be done with it?
It's amazing how much 'coverage' you get with standard MFC classes, without the ".Not" crap even. [of course turning _OFF_ the '.Not' crap takes extra effort, but it's worth it to me to do so] [assuming you still can in versions of DevStudio after 2010, that is]
oh - and last I checked, printf, scanf and FILE operations still work on windows, albeit a little strangely sometimes when you don't open with the 'b' flag and end up with crlf translation by default.
The functionality of Powershell may be similar to Bash, but the way it achieves it is very different.
In Unix, if you want to change something, you edit a text file. In Powershell, you issue a command. If you want to see what the current setting is, in Unix, you look at the text file, in Powershell, you issue a command to read the settings.
I still reckon the "smart" thing for MS to do would be to do an "apple" - take a flavour of *nix and make it just "work" and reliably work, not toss out some obscure error message - i.e. mint Tessa when I tried to install it on the wife's Dell XPS Ultrabook, why? because it came equipped with Optimus (dual GPUs with OS ability to switch between them), Linux doesn't play nicely with it at all, even went through umpteen "fixes" and still couldn't get the Nvidia GPU working without black screen instead of the GUI....
Got narked off in the end and sadly its going back to windows so the wife can get some work done on it (she's a designer and wanted linux on it, but only if the dual GPUs can be made to work.....3 hours later and no joy.....)
Yes I did install the closed source Nvidia drivers, both ones that Mint suggested and alternate ones from a suggested GPU driver repository and still no joy......laptop came close to being launched by the end.....many cryptic oaths were uttered, most of them in blue in colour.....
It should be easy to get a 7 year old laptop from a major vendor to work with a stable release of a popular distro....but no, it still in many use cases doesn't "just work" and thats infuriating, especially in a distro thats meant to be accessible to newer people. I'll give the mint community something, they tried to help me solve the problem, but I just couldn't get it working at all, it was either the intel gpu or no gui at all (logon sound played, could type the password, but couldn't see anything and couldn't figure why nothing appeared.
I'd pay money to a company for a product that could make stuff like that "just work out of the box", if something doesn't work, recognise something isn't right - please enter the following random string and press ok, if no string entered then auto rollback, prompt user after auto rollback with a list of options as to what might have gone wrong "screen black" "screen corrupted" "keyboard didn't work" "mouse stopped working" "something else" and then apply whatever fix is listed in its database / other collection of fixes, if it runs out of fixes it then asks the user for permission to "phone home" to look for other fixes or to get human interaction, user gives permission, connects, opens chat window, tech confirms the problem and what wasn't working that should have been, applies fix to get problem solved, if can't be solved user gets money back / tech feeds back to vendor / second level for creation of a fix....
You happy optimist, you.
Things will only ever "Just Work" out of the box once everything is controlled and specified, hardware, software, everything. Absolutely everything. That's how Apple can get away with saying it "Just Works" - by controlling the hardware. And even they can't always get it to "Just Work".
We're actually doing a pretty damn good job, so live with it and get on with your life...:-)
So why MS should take on OS that doesn't work with that hardware and spend resources to fix it, while its own one works already? Where is the sensible business case?
Face it - for most users that use Windows that came with their hardware, Windows "just works". They have all the required drivers, and unless the OEM screws up badly, the system works.
It's just a small subset of people that build/modify their own systems and keep on adding and remove hardware and applications that usually have issues, especially with cheap hardware and its cheap drivers. The Windows 9x times are really over.
The problem is the printer manufacturer - which usually don't release Linux drivers at all - not Windows. Usually happen for low-end cheap printers, which the manufacturer de-supports as soon as they are packaged for delivery.
Under Linux anyway you may not even have a driver for the printer at all - try to print under Linux on one of the Canon Pro printers (Pixma Pro and imagePROGRAF...)
Internet Explorer used to be "good" and people flocked to it, to the practical destruction of all else. Check out how that ended up. That's just one example of many.
The shell has been this stupid crappy old thing that nobody needs cos everything shall be done in GUI for years. Suddenly (ish) that message is changed. Does that not make anyone suspicious?
Both GUIs and command line tools have pros and cons - i.e. command line tools are quicker to use for simple tasks, and help to automate complex one, but become harder to use and error-prone when a task is complex, it's not automated, and you have little time.
GUIs help to navigate complex systems - changes can be applied and reviewed before being applied. They're especially useful to manage complex tasks that makes no sense to automate and help to minimize errors, and to monitor systems.
Thinking there's only One Anointed Way just leads to clumsier systems just more difficult to manage - especially when you don't spend every minute of your job managing only one, and can't really remember every switch and option.
I've always been amused by people who still use the old batch file commands rather than script (and there are people who do, people who should know better). Absent Powershell uses would have to learn to use scripts and so run the risk of learning that there are programming environments out there that are truly cross platform. They're extensible, too -- its not just that they usually have extensive library support that's readily available but also there is a very handy open source tool -- SWIG -- that allows you to easily write write extensions. Faced with the possibility that users may wander outside their ecosystem MSFT have provided a handy walled garden, their dot-Net world, where people can play and even convince themselves that its also cross platform. This, along with their WSL environment, should keep the sheep in the fold.
I retired recently which has finally allowed me to ignore Windows. I've been harried by this environment since the beginning, its OK for running cheap computers in but I have never been able to take it seriously because it just doesn't work for the world I worked in (embedded, communications and so on). Corporate believes in Windows, though, and no trouble and expense is spared trying to bend engineering to its will, resulting in an uphill struggle with unstable, unreliable development environments, applications groups that are unable to test anything properly because they can't work outside their Windows desktop -- a daily struggle. I'll let the Chinese take the strain......
(PS -- Anyone who thinks that they need to be a Perl Monk to write a simple Perl script needs to learn how to write software.....)
I'm not sure what point you are trying to make.
My most recent scripting exercise was automating the process of getting ssl certificates from LetsEncrypt and putting them in the correct places.
That involved both a bash script and a powershell script. The scripts were very different because the way the operating systems work is very different - using the certificate store api in Windows vs writing to a text file in /usr/local/etc/ (or /etc/ in Linux). If I wrote it in some other language that works on both platforms, it would still end up looking very different.
Biting the hand that feeds IT © 1998–2020