Slashdot Mirror
Microsoft PowerShell Goes Open Source and Lands On Linux and Mac (pcworld.com)
Microsoft announced on Thursday that it is open sourcing PowerShell, its system administration, scripting, and configuration management tool that has been a default part of Windows for several years. The company says it will soon release PowerShell on Mac and Linux platforms. PCWorld reports: The company is also releasing alpha versions of PowerShell for Linux (specifically Ubuntu, Centos and Redhat) and Mac OS X. A new PowerShell GitHub page gives people the ability to download binaries of the software, as well as access to the app's source code. PowerShell on Linux and Mac will let people who have already built proficiency with Microsoft's scripting language take those skills and bring them to new platforms. Meanwhile, people who are used to working on those platforms will have access to a new and very powerful tool for getting work done. It's part of Microsoft's ongoing moves to open up products that the company has previously kept locked to platforms that it owned. The company's open sourcing of its .NET programming frameworks in 2014 paved the way for this launch, by making the building blocks of PowerShell available on Linux and OS X. By making PowerShell available on Linux, Microsoft has taken the skills of Windows administrators who are already used to the software, and made them more marketable. It has also made it possible for hardcore Linux users to get access to an additional set of tools that they can use to manage a variety of systems.
Embrace, extend and extinguish ???
Link:
https://en.wikipedia.org/wiki/...
Everything I write is lies, read between the lines.
It looks as though MS has finally accepted the inevitable.
Though I shudder to think what hell may follow with MS getting it's fingers in the FOSS Pie.
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
Solutions to problems no one except windows admins are having. I don't think I'll lose much sleep.
Powershell isn't really a scripting language - it's a command parser where all the commands are like "Disassemble-the_Complicated-Dictionary-using-impossible-Format".
There is no God, and Dirac is his prophet.
Nope -- they only ruin Lunix. The BSDs are doing fine.
CLI paste? paste.pr0.tips!
If it's open sourced it can have the same amount of spyware the Linux kernel has if not less.
Powershell can be really powerful. Everything is a object and it allows you to easily write your own cmdlets and modules to extend the shell. No more parsing the text output of one command to create input to another. It's really very slick.
I use Powershell extensively to deploy applications using Microsoft SCCM at work. I use Linux the rest of the time. Bash scripting is very suitable to the way *nix commands work. Powershell is very suitable to scripting in Windows. I find PS very easy to learn and to work in, but only because I was already familiar with concepts like the pipeline (from Linux) and objects (from python ;-). I can create a PS script to install and configure an application quickly and easily because, just as in Linux there are commands that do everything you need to do, in PS there are cmdlets that allow you to easily (for the most part) access the various subsystems of Windows.
I see PS as a greatly improved, much easier way of doing what I used to struggle to do with vbscript or, a long time ago, with batch files.
That's why we have zsh and fizsh with syntax highlighting and all that fun stuff and other interpreters like tcl.
I've used powershell. It's the first thing I install on a Windows system if it's not already there.
It's fucking awful. The only useful thing about it is that the two letter unix commands are aliased, so I don't get a dumb error when I type ls.
The syntax of powershell is un-fucking-readable. You can type it with tab completion and aliases, but man, Looking.At.AlltheObjects.LabeledThis.Way for more than 15 minutes makes my eyes bleed.
Microsoft /could/ put REXX (or tcl!) in as a system scripting language, but since that makes too much sense, they'll never do it. They could do a lot of things that make sense, but we're talking about Microsoft here.
Pfui on PS.
--
BMO
Every once in a while I get told to run something under cmd.exe or PowerShell, and am reminded how incredibly limited these apps are when compared with any *nix *sh terminal app. Why does anyone think Linux users would take PowerShell over bash?
For many, working with an object-oriented terminal is immensely more preferable to having to wrangle text.
The reason for doing this I thought would have been obvious, but from the comments it doesn't seem so.
No Linux admin, who administers standard Linux bare metal or VMs is going to install this, not in a million years, they've got bash scripts with GNU utils, or they learnt Python or Perl or something else years and years ago, they've no use for PowerShell...
If however, you use Azure (MS *are* the second largest cloud computing provider), and you want to do web scale, Microsoft either needs to start giving out Perl and or Python modules, or they need to get PowerShell on Mac / Linux for people to be able to script their Azure / SQL / Exchange instances so that the admins and devs can integrate with Chef and everything else out there.
With the amount of work that's gone into Powershell for it to be an admins platform, it's *easier* to port Powershell to Linux than what it is to rebuild powershell for Python or Perl or whatever else.
Curiosity was framed; ignorance killed the cat. -- Author unknown
Clearly PowerShell is intended to manage systemd.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
sysctl and gconf anyone?
Has anybody looked at the .net open source to confirm if Microsoft code is actually quality or just lucky shit that just runs? Do developers(including contractors) hired by Microsoft code better than Open Source people?
Stupid questions, but, I read somewhere that someone at MS stated they just push code that works but does not necessarily mean all the bugs have been worked out.
Powershell has a very steep learning curve and IMHO lacks the end-user history of traditional unix shells.
That said... doing things like having most of your OS exposed through objects for inspection and manipulation, even cells in spreadsheets or network resources has value.
You *could* do this in bash with /dev/tcp/whatever, perl, sed, python and possibly an ldap client, but the exposed methods in powershell are more stable, have fewer dependencies and are easier to understand.
The fact that it's so hard to do simple things makes it very difficult to add to your knowledge without reading a few books or taking some course on the subject, then using it daily in Windows admin work.
I always wish I knew more about using it, but... unless you're deep in this stuff, it's better to skim the capabilities and let the Windows admins figure out the details.
Do you have problems comprehending . . . people's facial expressions and moods?
In a text thread? Not at all.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
How about letting actual Slashdot commentErs make the comments instead of building a ridiculous strawman? +4 Insightful, really?
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
Ever heard of awk and sed? I've been doing complex manipulations of data using tools like this for most of my IT career. Christ, I used awk to transform weird variant field exports from a mainframe to CSV to be imported into an inventory system while the most complex shell language Microsoft offered was the MS-DOS 6 command.com.
Honestly I think some of the people bragging up Powershell never really used *nix at all, at least not in any sophisticated way.
The world's burning. Moped Jesus spotted on I50. Details at 11.
And Office, and after seeing all the attempts at replicating it, Exchange.
Sorry, teleporters just kill you and then make a copy. A perfect, soul-less copy.
The dotnet core dev tools have telemetry built in and you are automatically opted-in. It can be turned off, but in typical MS fashion they slid it past everyone hoping it wouldn't be noticed. It's perfectly rational to suppose that the PS port has telemetry reporting features in it. I would assume it does and so should everyone else.
On linux, piping commands in bash are extremely limited. mostly because the command you pipe from cannot customize what data it is going to output to the command you pipe to.
Why exactly should it be able to customize output based on the pipe target? It sounds like something that makes commands work only with some specific other commands, seriously limiting reusability.
Yeah, almost everything that's genuinely useful limits reusability somewhat. By your logic, OOP "limits reusability" compared to raw assembly language, which allows you to do more things, including implementing your own OOP language in it. In reality, OOP tries to hit a sweet spot by constraining reusability somewhat and gaining functionality and ease of reusability for it. I've never used PS, but I understand that using object streams instead of text line streams will provide advantages. If the processes on both ends of the pipe declare what kind of objects the support, the shell can provide enhanced functionality if the processes support it, and fall back to text or to a generic meta object protocol otherwise.
Have you ever tried to grep from an mbox file all mails sent last month by a specific sender? That's gonna be next to impossible because grep doesn't know anything about mails, and because grep is line-oriented, but an mbox file doesn't contain one mail per line. OTOH if you can turn the mbox file into a stream of "Mail" objects, which it really is, the job is probably trivial even with any kind of "object grep" that just works via reflection and doesn't know anything about Mail objects specifically.
... For many ...
You keep using that word. I do not think it means what you think it means.
(best read in a pseudo-Spanish accent)
#DeleteChrome
ok seriously, does anyone else know of any shell that not only needs an entire framework install but also has 44MB of shit in it's source code?
Well, you need to understand that unix-based versions of powershell are actually being implemented through emacs.
#DeleteChrome
You would need to have the objects first. On windows you have objects representing registry keys, services, users, installed packages, processes, scheduled tasks, shares, office documents, etc. etc. - Powershell gets the power from that. And in order to be similarly powerful on Linux, it would need to have bindings for all that on Linux. Somehow I doubt that.
gci -recurse | sls 'hole_in_the_ground'
grep -r 'hold_in_the_ground'
Difference of about 10 characters.
Also... there is tab complete in PS just like in bash so....
Although, unlike in bash, tab completion also works for command line parameters as well so you wouldn't need to type all of "-Recurse" you would just need to type "-R" and then hit Tab once. so now the difference in keystrokes is fairly minimal.
My eyes reflect the stars and a smile lights up my face.
But with bash you can just start typing text. No need to look up obscure command system and object names if they only thing you want to do is get a list of all files matching a pattern. There's no text wrangling, you just start typing commands. And the same syntax you use for giving commands is used if you want a complicated script.
The difference is that Unix is oriented around commands and programs that take input and give output; whereas Windows is oriented around DLLs and frameworks that build on top of DLLs.
So dealing with those DLLs from a scripting language is very powerful, but those are inherently complex operations. The learning curve is like a brick wall. Unix builds on combining very simple operations into more complex results. If you only use powershell twice a year you'll forever be stumped and lost, but if you use bash only twice a year you'll still be able to get stuff done.
But with bash you can just start typing text. No need to look up obscure command system and object names if they only thing you want to do is get a list of all files matching a pattern. There's no text wrangling, you just start typing commands. And the same syntax you use for giving commands is used if you want a complicated script.
The difference is that Unix is oriented around commands and programs that take input and give output; whereas Windows is oriented around DLLs and frameworks that build on top of DLLs.
So dealing with those DLLs from a scripting language is very powerful, but those are inherently complex operations. The learning curve is like a brick wall. Unix builds on combining very simple operations into more complex results. If you only use powershell twice a year you'll forever be stumped and lost, but if you use bash only twice a year you'll still be able to get stuff done.
As someone who uses bash twice a month (red hat and ubuntu), finding some of the commands, or the correct syntax/switches frequently tends to be a frustrating experience. The man pages are occasionally helpful, but they're just as often a novel on something that's inapplicable, and missing the data I really need. That means a trip to google, and ending up on a blog page.
When I compare that to the documentation in powershell, man seems like an empty water bottle, and powershell's Get-Help is a river. I can Get-Help -examples to skip directly to syntax examples, and I'm moved on to the next step before I've gotten half-way through a man document that *may* or may-not help me. Also, the naming of commands in powershell is *predictable* which is a *huge* help. Get-Command Get-* will return all the available commands for retrieving information, and Set- * for setting whichever.
You can typically *guess* what a command does, just by looking at it. How frequently can you say the same for linux?
Learning *either* can be like a brick wall, depending on what that person has already learned, but I see powershell's documentation and the obviousness of it's command names lends itself to faster learning, including among a couple of linux admins I taught a little powershell to. They still prefer the bash terminal, but I see the fluency of their powershell scripts jumping when they use it every few months.
I want to run Powershell commands within a bash shell and be able to pipe their output to Unix utils, and I want to be able to run Unix utils in Powershell and pipe their output to Powershell commands.
I want to be able to mix and match them somehow.
Mostly, I think, the Powershell commands would be most useful paired with a bash shell and Unix utils, at least how I end up needing/wanting to use Powershell most of them time -- which I freely admit is biased by much more experience at a Bash prompt than a Powershell one, and mostly using Powershell commands to generate some kind of output that I want to work with Bash-style.
I recognize that merging them would be complex in some ways, as many Powershell commands return objects not output and the shell is just doing basic formatting of the object as textual output.
But maybe there could be some kind of hydbrid mode pipe operator that would just do the basic console output it would normally do, but send it to an instance of a Bash environment, or some way to access Powershell cmdlets from within bash as if they were normal programs that provided output.
But with bash you can just start typing text. No need to look up obscure command system and object names if they only thing you want to do is get a list of all files matching a pattern.
You must be one of those people who wonders why foreigners speak foreign languages when English is so much easier to learn! (Even our children can do it) Bash is not magically easier than PowerShell for someone who only uses it twice a year. In fact, I would say that PowerShell is easier because it has a lot of built-in aliases to make it familiar to *nix users.
Want to do a directory listing of all files matching a patter? Try ls *.txt. It will work in both bash and PowerShell. The arguments are different in PowerShell, but it's just a man ls to find out what they are (or just use the more convenient tab completion). Of course, those aliases are shortcuts to a verbose command naming scheme. I would think that for a very occasional user who might not remember the commands, it is far easier to use a system that has real descriptive names rather than the ultra-terse naming scheme used by *nix. Even if you can't remember the exact name in PowerShell, you can simply use a wildcard for the command name. Can't remember the command to export a CSV file? Type *csv* and keep pressing tab to cycle through the commands (or type man *csv* to see the entire list). If the occasional bash user had to export a CSV what would they do?
Also, PowerShell has a much more consistent argument naming scheme. The basic utilities on *nix have a diverse structure are arguments. For example, ls and find cover a similar subject, yet their arguments are worlds apart. You may be used to that, and so it seems familiar, but it is certainly not a simple case a sitting down and typing.
The difference is that Unix is oriented around commands and programs that take input and give output; whereas Windows is oriented around DLLs and frameworks that build on top of DLLs.
That is not an accurate assessment. PowerShell is all about commandlets and functions that take input and give output. The difference is that the input and output isn't just a stream of text, but objects. If you want to get the size of a file, you read it as a number; you don't have to convert the text in a particular position of a directory listing.
The pipeline is super-important in PowerShell. Objects, and lists of objects, are passed around and processed either sequentially or in a batch. The objects and pipeline are basically what gives PowerShell its power. To ignore that and talk about DLLs is just missing the entire point.
Articles:
.NET, Part 1 of 3. (Because the problem is in .NET.)
What I Hate About PowerShell
Is PowerShell really this bad?. Quote: "... the strangest mashup of Perl and VAX/VMS I've ever seen." Another quote: "... one of the most ass-backwards, lipstick on a pig, polished turd add-ons to the Microsoft stack in recent years."
Why Microsoft doesn't fix the long file name issues in PowerShell: Long Paths in
And don't forget the very poor writing quality of the documentation.