back to article PowerShell comes to MacOS and Linux. Oh and Windows too

Microsoft has given the world new versions of PowerShell that bring the popular automation and scripting tool to MacOS and Linux. PowerShell Core 6.0’s both an upgrade and a replacement for its predecessors. It’s a replacement because Microsoft is no longer actively developing its predecessor, “Windows PowerShell”. That tool …

  1. Tim99 Silver badge
    Windows

    PowerShell?

    If God had meant us to use PowerShell, He'd never have given us bash (Apologies to Flanders and Swann) - Having used both, I think I will continue to use a *NIX shell, thank you.

    1. JLV

      Re: PowerShell?

      upvoted, but it's a bit more nuanced than that.

      PS is extremely good at piping precise object streams from one process to another. For example, I know bash has stuff like pgrep or pkill, but you can see people recommending jumping hoops to pipe ps into grep and then parse out all the fields you don't want to get at the pid.

      PS needs none of that. Each step can feed exactly what's needed to the next and you have tons of filters/qualifiers to get exactly what you want.

      If you're in the biz of programmatically configuring systems, I think PS has the edge. You don't have to faff as much with cut/awk/grep on a text stream, you have an object stream instead. I think it's a bit like the power use you see with 'find' doing things through xargs - any pretense that it's simple goes right out the window at that point in bash. PS is like that from the start, seems like.

      Unfortunately, the number of options and qualifiers is massive and makes casual use of PS shell from the command line really unobvious for casual users, like me.

      ls -t => get-childitem | sort -property LastWriteTime

      ls | grep foo => get-childitem | Out-String -Stream | select-string -Pattern foo

      (the above is not a good way to look for *foo* files, but it shows how hard simple grep use can be. aliasing it to 'gci' or 'ls' doesn't fundamentally improve things...)

      Bash seems good to power users and admins alike. PS seems to really reward admins or ultra-power users because the learning curve is massive. Give me 3 weeks on it and I kinda get its basic usage. 3 weeks off, forgotten most of it again. Still better than cmd.exe though!

      That's my take, but I'd be happy to hear from people who've used both bash and PS in anger.

      A system that would support both paradigms would be awesome, but failing that I'll take bash over PS for my use cases. Even better would a system that mixed both. Still, hats off to MS here, they've been opening up quite a bit at the system level these last few years, much as I rag on Windows itself.

      1. richardcox13

        Re: PowerShell?

        > ls | grep foo => get-childitem | Out-String -Stream | select-string -Pattern foo

        Command line, so use aliases, and it is much simpler than that:

        dir | ? name -match foo

        1. JLV

          Re: PowerShell?

          ? is an alias for select-string here? sorry, I'd rather stick to the whole enchilada, these aliases are confusing me, if reference docs talk about select-string, sls or ? just add another layer of confusion, IMHO.

          the point I was trying to make is that you can't just "wing it" with a grep, you need to know your upstream object. if my ls wasn't just a plain ls, but an ls -l and if I wanted to find foo anywhere in its output, I'd have to cast the whole thing to a string because select-string wants strings and it's not getting them.

      2. TheGreatCabbage

        Re: PowerShell?

        I believe "ls | grep foo" could be accomplished using "ls | findstr foo" in Powershell :-)

        1. anthonyhegedus Silver badge

          Re: PowerShell?

          But grep is so much more natural to use. I mean you grep things, you don't "findstr" things.

      3. Professor Clifton Shallot

        Re: PowerShell?

        Yes, that's more or less how I see it.

        Those of us raised with tools like grep find it awkward to work the way we are used to when we move to Powershell but once there are people brought up in that environment they'll find it equally clumsy should they be asked to move in the other direction ('What do you mean it just returns a single property from each object combined into a text stream? I want my objects!')

        I don't know how useful it will be on my non-Windows systems but I'm certainly not going to rule it out just because it's Microsoft.

      4. Allan George Dyer
        Trollface

        Re: PowerShell?

        @JLV - So PS is a bit like Perl?

    2. Anonymous Coward
      Devil

      Sorry, both are products of the Devil itself.

      Only a very evil being could inspire the syntax used in those shells and their scripts.

    3. h4rm0ny
      Mushroom

      Re: PowerShell?

      Powershell is far superior to Bash and I call BULLSHIT on your suggestion that Bash is superior. The only problem with Powershell is a GNU/Linux environment is that GNU/Linux is not an Object Orientated environment whereas from top to bottom Windows is. Therefore Powershell can use it's far more advanced capabilities whereas on GNU/Linux it's stuck using the same kludgy approaches as Bash.

      You claim to have used both. Well I have to. Here's a short list of some of the things I can do in Powershell that I can't do in Bash. Oh - and syntactically it's more consistent and intelligent, too.

      1) Object oriented pipes so that I don't have to format and reparse and be concerned about language settings.

      2) Command metadata. PowerShell commands, functions and even *script files* expose metadata about the names, positions, types and validation rules for parameters, allowing the *shell* to perform type coercion, allowing the *shell* to explain the parameters/syntax, allowing the *shell* to support both tab completion and auto-suggestions with no need for external and cumbersome completion definitions.

      3) Robust risk management. Look up common parameters -WhatIf, -Confirm, -Force and consider how they are supported by ambient values in scripts you author yourself.

      4) Multiple location types and -providers. Even a SQL Server appears as a navigable file system. Want to work with a certain database? Just switch to the sqlserver: drive and navigate to the server/database and start selecting, creating tables etc.

      5) Fan-out remoting. Execute the same script transparently and *robustly* on multiple servers and consolidate the results back on the controlling console. Try icm host1,host2,host3 {ps} and watch how you get consolidated, object-oriented process descriptions from multiple servers.

      6) Workflow scripting. PowerShell scripts can (since v3) be defined as workflows which are suspendable, resumable and which can pick up and continue even across system restarts.

      7) Parallel scripting. No, not just starting multiple processes, but having the actual *script* branch out and run massively parallel.

      8) True remote sessions where you don't step into and out of remote sessions but actually controls any number of remote sessions from the outside.

      9) PowerShell web access. You can now set up a IIS with PWA as a gateway. This gives you a firewall-friendly remote command line in any standards compliant browser.

      10) Superior security features, e.g. script signing, memory encryption, proper multi-mode credentials allowing script to be agnostic about authentication schemes which may go way beyond stupid username+password and use smart cards, tokens, OTPs etc.

      11) Transaction support right in the shell. Script actions can join any resource manager such as SQL server, registry, message queues in a single atomic transaction. Do that in bash?

      12) Strongly typed stripting, extensive data types, e.g first class xml support and regex support right in the shell. Optional static/explicit typing. Real lambdas (script blocks) instead of stupidly relying on dangerous and error prone "eval" functions.

      13) Real *structured* exception handling as an alternative to outdated traps (which PowerShell also has). try-catch-finally blocks.

      14) Instrumentation, extensive tracing, transcript and *source level* debugging of scripts.

      15) Consistent naming conventions covering verb-noun command names, common verbs, common parameter names.

      1. Anonymous Coward
        Anonymous Coward

        " from top to bottom Windows is"

        No. Windows is still mostly a C API, which is not object oriented. It also has some C++ and COM APIs, which are object oriented, but which are not .NET objects. Powershell requires its wrappers over all of them.

        And frankly, I'd prefer to call a COM API than a .NET one. It doesn't require a specific VM, a JIT, and a framework just to call a function - and you can call it from many more languages and scripts.

        1. TheVogon

          Re: " from top to bottom Windows is"

          "No. Windows is still mostly a C API"

          Some of it, yes, but not mostly.

          "which is not object oriented"

          You are not understanding how this works. Windows from top to bottom can pass data as objects via it's management interfaces - what the underlying APIs use doesn't matter.

          "Powershell requires its wrappers over all of them."

          No, it doesn't. You might need a Powershell wrapper to say access a specific database as an object but the Windows OS access is baked in.

          "And frankly, I'd prefer to call a COM API than a .NET one."

          You don't need to care what it calls if your system supports .Net core.

          1. Anonymous Coward
            Anonymous Coward

            Re: " from top to bottom Windows is"

            Really, most of Windows is C API. And most of .NET (and Windows Runtime / COM) is a wrapper around the C API.

            Start reverse engineering things, and you notice that very quickly.

            Also, Powershell isn't a wrapper around .NET. It is .NET.

          2. Anonymous Coward
            Anonymous Coward

            "You are not understanding how this works"

            You are not really understanding what Windows is, and how PowerShell works.

            Like it or not, PowerShell commands ends calling or a Windows API (through its wrappers, it has to turn API calls into its .NET objects methods and properties, how do you think it happens, magically?), or an application API - which may be already a .NET one, or not, depending on what the application is coded with.

            WMI itself is a COM based interface, and it's obviously available with .NET since .NET - like many other languages - can call COM objects.

            Still "Windows from top to bottom" CAN'T "pass data as objects", because that's not how Windows is implemented. There is no, for example, file object in Windows. There are file handles, and file functions. Whatever you use to manipulate a file has to be a wrapper over these APIs.

            "You don't need to care what it calls if your system supports .Net core"

            Exactly - you need the whole .NET stuff to use PowerShell, and that's something I'd happily avoid. It's just another damned layer to keep updated (I'm really tired to apply .NET updates too), broadens the attack surface, and limits the number of languages you can use to manage Windows.

            Each and every management tool using PowerShell scripts is far slower and less user friendly than the previous tools using COM - and especially their error handling is awful. That's because the .NET overhead and piping of text data instead of native code calls and proper in-memory data structures and exceptions passed around (albeit marshaled when needed).

            1. Anonymous Coward
              Anonymous Coward

              Re: "You are not understanding how this works"

              "Still "Windows from top to bottom" CAN'T "pass data as objects", because that's not how Windows is implemented. There is no, for example, file object in Windows. There are file handles, and file functions. Whatever you use to manipulate a file has to be a wrapper over these APIs."

              Which as the OP stated above is done via the Windows management APIs. There is no "Powershell wrapper" as you claimed - it's part of the OS already.

              "Each and every management tool using PowerShell scripts is far slower and less user friendly than the previous tools using COM"

              Not true - Exchange and AD tools for instance are WAY faster - especially on multiple objects.

              "and especially their error handling is awful"

              No it isn't - Powershell tools write to the event logs just like the COM tools did - except with a much more granular level of detail.

              "That's because the .NET overhead and piping of text data instead of native code calls and proper in-memory data structures and exceptions passed around (albeit marshaled when needed)."

              .Net is very fast versus any other commonly used interpreted CLR model. Performance has never been an issue in any environment I have been in and I work in places with tens of thousands of boxes.

              If you look at benchmarks of .Net versus say C++ there usually isn't much in it ands .Net is sometimes significantly faster! See for instance https://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET

        2. h4rm0ny

          Re: " from top to bottom Windows is"

          >>"No. Windows is still mostly a C API, which is not object oriented. It also has some C++ and COM APIs, which are object oriented, but which are not .NET objects. Powershell requires its wrappers over all of them."

          No. Windows HAS a C API (and others). But pretty much every setting and configurable option in the OS is exposed as an object for use by Powershell.

          >>And frankly, I'd prefer to call a COM API than a .NET one. It doesn't require a specific VM, a JIT, and a framework just to call a function - and you can call it from many more languages and scripts.

          It's the 21st Century. It's okay to use languages that don't require an explicit compilation step. We're discussing Powershell vs. Bash. None of the above is relevant in a comparison of the two.

      2. TheVogon

        Re: PowerShell?

        "Powershell is far superior to Bash"

        Quite. I seem to recognise that list from somewhere...

        1. h4rm0ny
          Pint

          Re: PowerShell?

          Yes. I'm very sorry. Full attribution to The Vogon for that list. I had it floating around from a previous discussion. Sorry about that - I did credit you last time I posted it but I seem to have lost it this time. Mea Culpa.

          It's a good list. Pint as apology!

        2. Anonymous Coward
          Anonymous Coward

          Re: PowerShell?

          > Quite. I seem to recognise that list from somewhere...

          Sounds like the sort of stuff you use Node.js or Python scripts for. :-)

      3. cambsukguy

        Re: PowerShell?

        Wow, impressive capabilities, I wish I knew how to use it while being very glad that I don't.

        Having done some extensive <command> | <awk|sed|grep> ..., I wished all the time for something that *knew* what was coming.

        Not surprisingly, xargs is my favourite bash mechanism.

      4. Anonymous Coward
        Anonymous Coward

        Re: PowerShell?

        > 1) Object oriented pipes so that I don't have to format and reparse and be concerned about language settings.

        This is easily the best feature of powershell, but the rest of it is just so bad it fails to redeem it.

        Also some of your other points do exist in other shells.

        The surprising thing is that bash can compete at all, given the 40 odd years between them, and yet it does.

      5. Anonymous Coward
        Anonymous Coward

        Re: PowerShell?

        > "9) PowerShell web access. You can now set up a IIS with PWA as a gateway.

        > This gives you a firewall-friendly remote command line in any standards compliant browser."

        Is that entirely wise?

        1. Anonymous Coward
          Anonymous Coward

          Re: PowerShell?

          "Is that entirely wise?"

          Why wouldn't it be? It's just like accessing say Bash via SSH, but far more practical, flexible and firewall friendly with far more security options.

          1. Tom 38

            Re: PowerShell?

            It's just like accessing say Bash via SSH, but far more practical, flexible and firewall friendly with far more security options.

            This is where the Powershell advocates aren't understanding the UNIX advocates. UNIX has a philosophy:

            Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface

            and we try to stick to it. This is why Powershell has a long "feature list" that bash does not have. UNIX developers would not put remote access features in to a shell, because remote access features are not part of a shell.

            Microsoft has a different approach, they tend to put every feature that they can think would be useful in to a product. To someone who embraces the UNIX philosophy, that is abhorrent, so depending upon your philosophy, you can consider bash superior to Powershell, or vice versa.

      6. Anonymous Coward
        FAIL

        Re: PowerShell?

        Powershell is far superior to Bash and I call BULLSHIT on your suggestion that Bash is superior.

        Well, you sound like a blithering idiot saying that. Apart from #2, none of those are geared towards a shell. You might as well have described be benefits C#, or compared VBA to batch files.

        The trouble with bash is people think it's a scripting language, when it's not. It's the equivalent to batch files - more than a screen-full, then you need a good reason to not use something else.

      7. nijam Silver badge

        Re: PowerShell?

        Giving a long list of features in PowerShell does not imply that it is superior. A casual glance, in fact, reveals that almost everything in the list is either essentially meaningless (e.g. "True remote sessions") or has no place in a shell (e.g. "web access").

        1. Anonymous Coward
          Anonymous Coward

          Re: PowerShell?

          "is either essentially meaningless (e.g. "True remote sessions")"

          Just because you don't understand the advantages doesn't make it meaningless. You can run Powershell directly against remote machines without having to pipe connections via SSH, etc.

          " or has no place in a shell (e.g. "web access")."

          So say SSH has no place connecting to a Shell?

          1. Tom 38

            Re: PowerShell?

            Just because you don't understand the advantages doesn't make it meaningless. You can run Powershell directly against remote machines without having to pipe connections via SSH, etc.

            Yes, really, I get it! I just think it is an awful idea. The two things are not related.

            So say SSH has no place connecting to a Shell?

            No, of course it does not. "The shell" and "how you get remote access to a shell" are orthogonal concepts, implemented in separate programs. The shell doesn't care how it is connected to its user, and the transport doesn't care what it is transporting.

            Like I said, whether you agree with this or not will depend on whether your viewpoint is "small programs that do one thing that you can combine with many other programs that also do one thing" is good, or whether you think "one program that can do everything we need in all possible scenarios" is a good thing.

            Not to cast too many aspersions, but the best designed, most complex and maintainable a system is, the more likely it is composed of many small programs that do one thing.

      8. Voland's right hand Silver badge

        Re: PowerShell?

        Powershell is far superior to Bash

        At the point you are demonstrating the syntax is abominable so while you can wing all 15 use cases after quad espresso and an amphetamine chaser, doing so in a business environment should be a sackable offense.

        If you want to use it for something THAT level of complexity neither bash, nor powershell do the job. You need to use a proper language, have test cases, unit testing and possibly integration testing. Sure, you can cook it in bash or ps instead of let's say python, but that means that you need to find someone capable of consuming the same speed flavored quad espressos to maintain it.

        Both PS and Bash have lost the plot - they now allow what is effectively software development while having a readability compared to which badly written Perl reads like Shakespeare sonnets. No thanks, if someone starts building production code using either, sacking is the right thing to do.

      9. Martin
        Happy

        Re: PowerShell?

        Powershell is far superior to Bash and I call BULLSHIT on your suggestion that Bash is superior.

        And yet, only today, there was an article in El Reg bemoaning the fact that there are no more religious wars in IT.

      10. bladerunnerblues@gmail.com

        Re: PowerShell?

        "6) Workflow scripting. PowerShell scripts can (since v3) be defined as workflows which are suspendable, resumable and which can pick up and continue even across system restarts."

        I would like to know more. Really need this is some of my scripts.

        1. Uffe Seerup

          Restartable (across system restart) powershell scripts

          > I would like to know more. Really need this is some of my scripts.

          See this article:

          https://blogs.technet.microsoft.com/heyscriptingguy/2013/01/23/powershell-workflows-restarting-the-computer/

          When using Powershell to script "workflows" a subset of powershell cmdlets are supported. IIRC you can create a "script step" if you want to use non-workflow cmdlets.

    4. Anonymous Coward
      Anonymous Coward

      Re: PowerShell?

      >> If God had meant us to use PowerShell, He'd never have given us bash

      You realise that Powershell is way more powerful, capable and secure than Bash? There was a long long list of advantages previously posted here.

    5. Anonymous Coward
      Anonymous Coward

      Re: PowerShell?

      Why do people compare Powershell to bash?

      It's a very capable scripting language, but an appalling shell. Bash is the reverse.

      You're better off comparing it to node or python.

      1. h4rm0ny

        Re: PowerShell?

        >>Why do people compare Powershell to bash?

        Seems to be mostly GNU/Linux users who need to assert that their OS is better than another. Command Line has historically been a notable differentiator between GNU/Linux and Windows. And so its arcane spells and incantations became a badge of superiority over dialogue boxes and configuration wizards - because if you need to be smarter to use it, that shows it's the tool for smart people. *ahem*

        When Microsoft looked at Bash and said: "You know, if we can make this a bit less idiosyncratic and do it in a modern way, it would be pretty useful to us, too" it was like Steve Balmer had personally mugged Brian Fox at gunpoint to these people. (Even though as you point out, Powershell and Bash have basic, conceptual differences). It became vital to prove that Powershell, despite being newer and benefiting from building on everything that came before it, was inferior to Bash. Because otherwise GNU/Linux gurus couldn't point at a pile of (unsigned, downloaded from the web) scripts and say: "See! Better!"

        >>It's a very capable scripting language, but an appalling shell

        Well it's not really a shell. I fire up ISE (Integrated Scripting Environment) which comes as standard on Windows rather than the basic Powershell interface and it works great as a shell for me. (Only time I use the other interface is if I'm CLI'ing in Python or something and I need stdin style interaction).

        >>You're better off comparing it to node or python.

        By language design, yes. But it's so handy for sysadmins managing Windows systems that it occupies the same user space as Bash.

        1. Richard Plinston

          Re: PowerShell?

          > Command Line has historically been a notable differentiator between GNU/Linux and Windows.

          Mainly because Microsoft spent decades denigrating 'command line' and deliberately crippling their own. For example 20 years ago in Windows 95 they included a command line editor, doskey, but it wasn't available by default and wasn't documented. The initial development version of Windows 98 did not even include a DOS box or a command line (that had to be fixed).

      2. phuzz Silver badge
        Thumb Up

        Re: PowerShell?

        "[Powershell is] a very capable scripting language, but an appalling shell. Bash is the reverse."

        Ahh, thankyou AC, this is what I've been thinking for years, but never managed to put into words.

      3. Anonymous Coward
        Anonymous Coward

        Re: PowerShell?

        "It's a very capable scripting language, but an appalling shell. Bash is the reverse."

        No, Powershell is also a better shell too. Scripting is after all just creating a series of shell commands.

    6. Naselus

      Re: PowerShell?

      This is a stupid argument.

      If you're used to Bash, use Bash. If you're used to Powershell, use Powershell. Bash is better for Linux administration but pretty hamstring for Windows, while Powershell integrates with Windows perfectly but isn't likely to be doing anything exciting on Linux.

      I see this rather more as giving you the option to use the right tool for Linux-to-Windows administration (since 90% of your client machines are likely to be on Windows even if your engineers are using Linux), rather than an attempt to supplant Bash on Linux-to-Linux admin tasks.

    7. Anonymous Coward
      Anonymous Coward

      Re: PowerShell?

      > Having used both, I think I will continue to use a *NIX shell, thank you.

      Linux type of 23 years here, and Unix before that, but what is wrong with having choice? It is not exactly a binary decision, is it?

      Never used PowerShell, but good to know I can if I ever need to.

      1. Anonymous Coward
        Anonymous Coward

        Re: PowerShell?

        Heretic

  2. doug_bostrom

    PowerShell on Linux. That's rich. "Here, Yoda, let me show you how to use that there force."

  3. Steve Davies 3 Silver badge
    Mushroom

    Powershell == Invasion of the body snatchers

    There is no way that I'll ever, ever, ever let it near and Linux or MacOS system of mine.

    If it appears then I'll press that big red button myself.

    After spending a week battling with MS over why the MSCS bits had dissappeared from a server after the application of a patch and rolling it back made it appear again, I would have liked to do real harm to the people responsible.

    They eventually issued the patch again and fixed it but being in S. Asia at the time and with the customer threatening to cancel our $4M contract over the non deliver of clustering, it still gives me the heebies and that was in 2015.

    1. Anonymous Coward
      Anonymous Coward

      Re: Powershell == Invasion of the body snatchers

      There is no way that I'll ever, ever, ever let it near and Linux or MacOS system of mine.

      Ditto. I like tools that are native to the environment. In addition, we have become allergic to Microsoft offering *anything* for free because we know there is a price to pay later (based on a 30+ year track record), we rather continue to actively avoid any Microsoft entanglement. At most, they get to run a desktop environment where we haven't replaced it yet with something that costs less and is easier to maintain, but we no longer allow anything MS made deeper into operations.

      If we need anything automated we'll use Unix tools, but for anything complex there will be use cases, analysis and proper coding in a language rather than shell scripts - in a Unix environment.

  4. hplasm
    Meh

    Next up-

    Tits on a fish.

  5. Dwarf

    Poor old MS

    Still trying to remain relevant, no phone OS, an unloved client OS, a declining user base, a disliked speech app and a far smaller set of tech evangelists as they stopped listening and providing TechNet.

    There’s no way I’ll be using this on any non-Windows system as the built in tools have been doing nicely for years.

    1. TheVogon

      Re: Poor old MS

      "Still trying to remain relevant, no phone OS"

      Microsoft are still developing Windows 10 mobile. To run on what is more the question! And we know that Andromeda is coming which will merge Windows Mobile and Windows capabilities so they haven't given up yet.

      "a declining user base,"

      Nope - Microsoft's user base is still growing.

      " and a far smaller set of tech evangelists as they stopped listening and providing TechNet."

      That did suck. But people were flogging the license keys on eBay.

      1. Doctor Syntax Silver badge

        Re: Poor old MS

        "And we know that Andromeda is coming which will merge Windows Mobile and Windows capabilities so they haven't given up yet."

        Wasn't that Windows 8? And 8.1? And 10?

        1. Anonymous Coward
          Anonymous Coward

          Re: Poor old MS

          "Wasn't that Windows 8? And 8.1? And 10?"

          No. It's a future version of 10.

      2. Richard Plinston

        Re: Poor old MS

        > Microsoft are still developing Windows 10 mobile.

        We know that you only live to evangelise Microsoft but do try and keep up:

        https://www.rte.ie/news/technology/2017/1010/911243-microsoft-to-stop-developing-windows-10-mobile/

    2. Phil W

      Re: Poor old MS

      "an unloved client OS"

      Yeah, not like Windows is the world's most used operating system on desktop or anything....

      1. Dwarf

        Re: Poor old MS

        Don't confuse those who are stuck on Windows vs those who like the product.

        You might want to research market trends on desktop PC sales, Those who are not stuck on Windows have moved away to products such as Mac, Linux, Tablet devices, mobile phones, etc.

        Now go and re-consider if its "the most used OS on desktop or anything" - you will find that its not.

        For starters, they only have desktop and tablet offerings, with tablet being a poor second cousin to other competing tablet offerings

        If you take a blinkered look of "Microsofts historical market segment", which has two products - Windows and Linux, then yes, its in the lead a the moment, but that lead continues to decline as people look to other more viable products.

        This shows that its an unloved OS, otherwise market segment would be increasing and they wouldn't have to have needed to try and give it away.

        1. Phil W

          Re: Poor old MS

          Your reply is self contradictory, in one breath you say

          "Now go and re-consider if its "the most used OS on desktop or anything" - you will find that its not."

          and then follow it up with

          "If you take a blinkered look of "Microsofts historical market segment", which has two products - Windows and Linux, then yes, its in the lead a the moment"

          Microsoft's historical market segment, i.e. desktop PCs and laptops, hasn't really changed. Regardless of any marketing hype that has always been and continues to be their largest market (other than Office which is really part of that same segment anyway, although now includes mobile apps on various platforms).

          Sure there are tablets to consider, but a Windows tablet is just a laptop in another form factor, and an Android tablet or iPad is a mobile phone in another form factor, they aren't part of the same market segment.

          http://gs.statcounter.com/os-market-share/desktop/worldwide/#monthly-201712-201712-bar

          This isn't a totally accurate source, since it depends on web browser usage, so devices that are not used to access the Internet are not included, but even if you cut the Windows lead in half it's still well ahead as far as desktop goes.

          Mobile of course is another story entirely

          http://gs.statcounter.com/os-market-share/mobile/worldwide#monthly-201712-201712-bar

          Regardless of whether it has declined/is declining (which I would argue it isn't but that's by the by), it is a simple fact that some form of Windows from XP-10 is currently the most common OS on desktop PCs and laptops for both home and commercial use by quite a significant margin.

          If you think otherwise I would love to know what you think the most commonly used desktop OS is.

          1. Dwarf

            Re: Poor old MS

            If you re-read my original posting, you will see that I say its the un-loved OS. People are using their wallets to buy other products, nobody wants to buy Windows 10 and MS decided to force it down our throats, this left a bad taste for many people and plenty of non-working systems.

            If memory serves, Windows 8 came out in Aug 2012 and Windows 10 came out in the first half of 2015, look at the attached stats of global PC sales and see what happens at those dates. As the world population is increasing, what other reason can you think of that might explain why the last couple of OS's MS shipped maps to decreased sales ?

            Simple - its unloved and people are moving to other things or keeping their old hardware and re-purposing it (ie installing Linux)

            Declining sales - same trend, different information source

            If you take an average train trip as representative of people, you will see a couple of corporate sales types with their work provided laptops doing e-mail and WhatsThePoint presentations, plenty of people of various generations with their Mac's, various non-MS tablets and phones, very few have Laptops running Windows.

            I'm not disagreeing that Windows has a large existing install base, mostly this comes from history and businesses where they can't move so easily, but many are reducing their exposure or opting for cheaper alternatives where they can - thin clients, web interfaces, Linux back-ends, etc. The general trend to PaaS platforms has helped to decouple the MS attempts to bind the client and server components together. Now that they are decoupled, who still uses IE why did nobody move to Edge ? Thats because they all moved to Chrome, yet another MS fail to deliver what customers want.

            So, here's a question for you - do you think MS realise that they are loosing significant market shares and are trying to diversify with their attempts to get MS SQL and Powershell onto Linux and stick a Linux shell onto Windows, or do you just think they are being nice ...?

            If you think the latter then ask yourself, have you ever seen them be nice before ??

    3. Anonymous Coward
      Anonymous Coward

      Re: Poor old MS

      > an unloved client OS,

      I was trying to do some stuff on a borrowed computer the other day. It was Windows. Man, does it feel like a throwback to the 90s or what, usability-wise!

      The other couple of things that bother me about that offering are the noise (of data being slurped as you type) and the feeling that it is more of an advertising platform than an OS.

      With that said, they have been getting closer to Unix since the NT days, and the pace is picking up. I reckon in ten years or so Windows will be a compatibility layer over a *nix / BSD system, rather than an OS in its own right. Not passing judgment on whether that's a good or a bad thing, just pointing out that's the way things are headed (twenty years behind Apple, mind).

      Other than that, Microsoft itself is a very different entity than it was in the 90s and early 00s. Shame they lost about a decade while that weird bald guy was at the helm.

  6. Pascal Monett Silver badge

    Oh how the mighty have fallen

    "That idea’s fuelled by Redmond’s belief that in a hybrid cloud world there’s every chance you’ll wrangle Windows or Linux servers from a Mac or penguin-powered machines. Or even a Windows PC."

    I remember a time when Microsoft refused to even consider that there was anything but Windows. A time when it actively tried to thwart Linux from booting. A time when it crippled it's own Office if it wasn't running on a Windows platform. It was the Microsoft Way, or the highway.

    It seems that the continuous string of investment failures has finally bowed the head. Yes Microsoft, you're right ; there is every chance that cloud servers will be administered from something other than a Windows PC and, as time goes by, there is more and more chance that the server won't be Windows either.

    1. Anonymous Coward
      Anonymous Coward

      Re: Oh how the mighty have fallen

      "It seems that the continuous string of investment failures has finally bowed the head. "

      You must have missed Microsoft's share price recently. They overtook AWS in cloud revenue run rate 2 quarters ago.

      "there is every chance that cloud servers will be administered from something other than a Windows PC"

      Most likely from a Windows based tablet like a Surface.

      "as time goes by, there is more and more chance that the server won't be Windows either."

      No sign of that so far. Microsoft's server share is still growing.

      1. Pascal Monett Silver badge

        Ah, share price, that's your fall-back argument ? The disappearance of Windows Phone means nothing to you, then ? Cortana shutting down is of no consequence ? Sure.

        As for server share, you obviously haven't got a clue.

        Keep drinking the Kool-Aid. A numb mind is a pleasant thing.

        1. Anonymous Coward
          Anonymous Coward

          >As for server share, you obviously haven't got a clue.

          That is just public-facing web servers. In the latest figures for December, Windows (IIS) has dropped by a few % in the last 8 years. Over that same period, Apache has lost 20% to nginx. Web servers is the tip of the iceberg though - and the number is not unique web servers, but sites served...

          In the clients I've seen, you are looking at something like 70% Windows boxes on the internal servers. YMMV though.

    2. Anonymous Coward
      Anonymous Coward

      Re: Oh how the mighty have fallen

      " A time when it actively tried to thwart Linux from booting."

      Has that time actually passed? I haven't noticed, I still follow the procedure:

      - Install Windows first

      - Install Linux

      - Use Grub(2) as bootloader

      I've never thought to change. Does the Windows boot loader recognise and provide a Linux option if you do it the other way around now? I know you could manually tweak the Windows boot loader to boot a Linux install, but it was faffing* compared to the steps above, but that demonstrates it was always possible.

      If the above is true, and installing Windows doesn't nuke a working Linux, I'll take my hat off to MS.

      * I believe it was something like dd'ing the first few KB/MB of the disk (the MBR possibly) and providing that as an image to the Windows boot loader

      1. Wensleydale Cheese
        Happy

        Re: Oh how the mighty have fallen

        "Does the Windows boot loader recognise and provide a Linux option if you do it the other way around now?"

        I got this working with Windows Server 2008 and Windows 7 back in 2010. It was the saner way to go because Windows didn't overwrite its own boot stuff at random intervals.

        But then I discovered VirtualBox[1] and dual booting became history. I'm not a games fan, so don't need the raw graphics performance of Windows running as the host.

        [1] I've moved on to other virtualisation systems nowadays, since I wish to steer clear of the Oracle licencing which comes with VirtualBox Extensions.

  7. Anonymous Coward
    Anonymous Coward

    land grab...

    ...seems like an attempt at land grabbing.

    Slowly educating Linux peeps to the ways of the dark side :)

  8. Shelleycat

    No man

    They deliver a complex language without the help. Makes it very hard to use on something you cannot install the help on.

    1. TheVogon

      Re: No man

      "They deliver a complex language without the help"

      Erm, no. Just type Update-Help and then Get-Help

      1. Anonymous Coward
        Anonymous Coward

        Re: No man

        or even just man

  9. jonha

    In 10 years (give and take) Windows will be based on a Linux kernel. In a way, Windows *will* be Linux. (I am off Windows since v8 and do not look forward to that..)

    1. TheVogon

      "In 10 years (give and take) Windows will be based on a Linux kernel."

      Seems unlikely - a modern hybrid microkernel has several advantages. More likely Linux when needed will run as a plugin to the Windows kernel. In fact you can already do that under Windows 10.

      1. Roo
        Windows

        "Seems unlikely - a modern hybrid microkernel has several advantages. More likely Linux when needed will run as a plugin to the Windows kernel. In fact you can already do that under Windows 10."

        IMO your strengths lie in FUD and bullshitting, best to keep out of the OS design biz. :)

        Microsoft have already failed to assimilate POSIX with a plugin approach repeatedly. Running the code on a real UNIX/Linux was always cheaper, faster and more reliable - and didn't require a "porting" effort... MS are best to stick with running Linux under their Hypervisor and be happy that they get an OS license for running workload under someone else's OS.

        As for Windows having a "hybrid microkernel" architecture, that is just marketing shite. The point of a microkernel is that the subsystems are isolated. It is fraudulent to attribute the term 'Microkernel' to something that shipped with vulns that allowed TrueType Font rendering to pwn ring0.

        I don't mind folks talking up the benefits of Windows, but I draw the line at them rendering useful terms and concepts such as "Microkernel" meaningless by association.

    2. Naselus

      "In 10 years (give and take) Windows will be based on a Linux kernel."

      Yes, and no Linux prediction has ever been over-optimistic before. Which is why every year since 2002 has been the Year of Linux on the Desktop.

    3. Anonymous Coward
      Anonymous Coward

      I've been always surprised how much Linux punters advocate "choice", "freedom", but they hope to have only one kernel and one OS to rule them all. Good-bye then to to any choice and any freedom.

      Basically, still putting all power in the hands of a very limited group of people fed by a few large organizations with no competition, which may have very little interest in end-user real needs, only in their very own. Just look at Google and Facebook.

      Is it OK to have no choice, as long the ruler is not Microsoft? Looks very naive and stupid to me. The alternatives are no better. Let them compete against each other.

      You may like Windows or not, but having different operating systems in competition is better than only one with no competition (you can't buy macOS outside Apple hardware, so it's not real competition). Different distro are just some different bells and whistles on the same package.

      It looks Stallman hypocrisy trickled down to most Linux advocates. When they talk of freedom is just to enslave you in a system where they hope to be the rulers.

      1. Adair Silver badge

        A response to ...

        'I've been always surprised how much Linux punters advocate "choice", "freedom", but they hope to have only one kernel and one OS to rule them all. Good-bye then to to any choice and any freedom.'

        Personally I've only come across that attitude amongst the immature 'script kiddy' end of things. Most people I know who prefer Linux to Windows don't want Linux to replace Windows, they just want such a shonky toy of an OS as Windows is to disappear into a corner, die if it must, but otherwise just be there for anyone who is interested, just so long as it ceases to have any relevance in environments where 'real computing' gets done, and where the people concerned need to have access to and control over what their chosen OS (Linux or whatever) is doing.

        As for the great unwashed who can just about find the I/O switch, they deserve better too.

    4. jimbarfield

      They are really very similar aside from licensing. I know that people will slam me for saying that- the way Windows handles permissions- but really it comes down to usability. Yes they are different -but also increasingly show similar aims

    5. Anonymous Coward
      Anonymous Coward

      >>In 10 years (give and take) Windows will be based on a Linux kernel

      Linux is already running on the Windows kernel via Ubuntu on Windows 10. Which makes more sense than Windows running on the Linux kernel.

      1. Richard Plinston

        > Linux is already running on the Windows kernel via Ubuntu on Windows 10.

        No. Wrong. 'Linux' is the kernel. That is _not_ running on Windows 10. What is running on W10 is GNU software: bash and many utilities; plus other FOSS software, but _not_ 'Linux'.

  10. chivo243 Silver badge

    MS Smells Coffee

    MS Maturing these days? Realizing that they have to work with the rest of the tech world in order to stay relevant?

    Seems this article might reignite some of the old and forgotten flame wars the article below says are gone?

    https://www.theregister.co.uk/2018/01/12/end_of_the_tech_religious_wars/

    1. Anonymous Coward
      Anonymous Coward

      Re: MS Smells Coffee

      40% of azure instances are Linux.

  11. Anonymous Coward
    Anonymous Coward

    Get-Lost

    1. OJay

      get-lost : The term 'get-lost' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

      You tricked me!

  12. simpfeld

    Bash is superior but isn't supposed to be as feature rich as PS

    So many people here are posting things BASH can't do but PS can. But BASH wins on simplicity to do relatively simple things. PS syntax like most MS things is flabby and non-obvious.

    Lesson one any Unix admin learns, is know when your task is too big for the shell and time to switch to back in the day Perl now Python et al.

    1. Anonymous Bullard

      Re: Bash is superior but isn't supposed to be as feature rich as PS

      Exactly. They should have called it "Powerscript".

      If you're at the point where you need to compare bash to powershell, then you're using either one of them wrong.

      1. JLV

        Re: Bash is superior but isn't supposed to be as feature rich as PS

        >you're using either one of them wrong.

        That's a nice quip, but what should the stereotypical power user - emphatically not a sysadmin - use as a Windows command line then?

        Same question applies to those who state that PS is closer to a full-on language than a shell. What is the MS solution to basic user productivity tasks on the command line, if that's not really PS's design goal?

        Honest question.

    2. nijam Silver badge

      Re: Bash is superior but isn't supposed to be as feature rich as PS

      If you're into such things, bash also has many features that powershell doesn't - and they're actual shell features, unlike the tedious list (posted earlier) of things that powershell has that are not shell features.

      Windows has always been clunky and obstructive; powershell just seems to be more of the same. Much more.

      1. Anonymous Coward
        Anonymous Coward

        Re: Bash is superior but isn't supposed to be as feature rich as PS

        "If you're into such things, bash also has many features that powershell doesn't "

        Oh really, like what? Bet you cant name even ten things you can do in Bash that you cant do an equivalent of in Powershell.

    3. Anonymous Coward
      Anonymous Coward

      Re: Bash is superior but isn't supposed to be as feature rich as PS

      "But BASH wins on simplicity to do relatively simple things."

      On the contrary, PS is much simpler to use in most cases - especially as you simply don't need to do the parsing and formatting of the output to pipe it that you commonly do in Bash.

      PS syntax like most MS things is flabby and non-obvious."

      You clearly have not actually used Powershell to any significant degree. The syntax and formatting is utterly consistent and common sense throughout, unlike Bash where it varies massively on a command by command basis and relies on completely non intuitive switches and options.

  13. Zippy's Sausage Factory
    Mushroom

    Personally, I have had to work with many shells over the year, PowerShell included. I hate most of them, and try to avoid them where possible. bash, ash, zsh and csh are fairly annoying, but livable with. Command prompt I can get by in. It's dumb as a rock but it works.

    PowerShell, however, makes me want to get very very rich. Rich enough to buy a controlling interest in Microsoft. Rich enough that on my first day I can say "I want PowerShell dead. Erase the source code, fire everyone who ever worked on it and remove it from every single product this company makes. Then go through the corporate website and delete every single page about PowerShell and ever single reference to PowerShell from every other page."

    Then, and only then, will any action taken with regard to PowerShell please me.

    tl;dr: I don't like PowerShell.

    1. HmmmYes

      Does you PS scripts take a long time to run too?

      Does your command completion spin air for ~3s seconds whilst PS does 'something'?

      1. Anonymous Bullard

        That's not powershell's fault. I've just installed it on Linux, and it's almost instant.

        ¯\_(ツ)_/¯

      2. Anonymous Coward
        Anonymous Coward

        "Does you PS scripts take a long time to run too?"

        No, Powershell is very fast and efficient. Especially compared to sequential solutions like Bash when you use it's true parallel script branching.

        "Does your command completion spin air for ~3s seconds whilst PS does 'something'?"

        Only either while it starts up and parses it's environment for the first time and loads any installed modules. For instance on a Windows 10 default install, Powershell takes about 1 second to get to a command line the first time launched in a session and is near instant when subsequently launched.

  14. g00se
    Linux

    Shell without Power

    The big plus with Powershell, as has been mentioned above, is that it allows object-oriented access to system objects. That's not relevant with Unix-like OSs. Strip it of that superset of functionality and you might as well use the shells already available for those.

    1. Anonymous Coward
      Anonymous Coward

      Re: Shell without Power

      I don't like Powershell because it can do too much...

      That may sound a bit odd, however..

      This leads people to essentially write complex applications in PS - not just use it for simple tasks.

      If they had done it in C# (e.g. chosen as as that runs on CORE) with proper test cases etc then great, but instead you end up with application level scripts, without rigorous automated test regimes, and a nightmare f something goes wrong.

      .. I have seen fiendishly complex Powershell scripts many pages long - which is not good for maintainability / trouble shooting / testing

      We now have a limit on size / complexity of PS scripts

      Powershell seems to have become the new equivalent of people writing (un-controlled) apps using VBA in Excel.

      As the saying goes:

      "With great power comes great responsibility"

      Unfortunately, PS is, far too often, not used responsibly.

      1. Anonymous Coward
        Anonymous Coward

        Re: Shell without Power

        "but instead you end up with application level scripts, without rigorous automated test regimes, and a nightmare f something goes wrong."

        Well Powershell Is just as good as say C# that you mention for that if you choose to write the test cases. And in many ways better and easier to debug.

        ".. I have seen fiendishly complex Powershell scripts many pages long - which is not good for maintainability / trouble shooting / testing"

        That's in no way an issue with Powershell. If people write undocumented and uncommented code in any language you would have a similar issue. As per the list above, Powershell gives you the following key features among many others to help with that:

        13) Real *structured* exception handling as an alternative to outdated traps (which PowerShell also has). try-catch-finally blocks.

        14) Instrumentation, extensive tracing, transcript and *source level* debugging of scripts.

    2. Anonymous Coward
      Anonymous Coward

      "allows object-oriented access to system objects"

      That's what SOM (System Object Model) in OS/2 allowed, and later COM in Windows.

      The idea was to expose OS and application APIs through common, language agnostic OO interfaces. And it was twenty-five years ago.

      PowerShell is instread a .NET-only implementation with a far worse and cumbersome syntax, and with far less control on execution, especially error handling.

    3. nijam Silver badge

      Re: Shell without Power

      > That's not relevant with Unix-like OSs

      Or with Windows, either. Maybe with some of the applications and libraries larded on top of it, who knows?

  15. Anonymous Coward
    Anonymous Coward

    The only Power I get from Shell is in my car

    1. Anonymous Coward
      Anonymous Coward

      "The only Power I get from Shell is in my car"

      That's the blue Powershell, yes? I'll be right behind you until we're nearly at the finish line...

  16. Dick Kennedy

    Great - now we can have fileless malware running or more platforms. After all, PowerShell is the choice of hackers everywhere...

  17. Anonymous Coward
    Linux

    RESTful APIs

    I use both PowerShell and Bash regularly. One thing PowerShell is great for is ad-hoc manipulation of RESTful APIs from the command line. Using the Invoke-RestMethod cmdlet (http://go.microsoft.com/fwlink/?LinkID=217034), one can run commands against a web API and get back objects which can then be directed at a pipeline of other PowerShell commands to do what you like.

    It has been noted by some above that Windows is "object-based" (good for PowerShell pipelines) and Unix is "file-based" (good for bash pipelines), but a lot of systems that we admin these days have moved to the cloud and work has to be completed using web APIs. PowerShell is a nice tool for this.

  18. ranger

    I've been using Powershell as my main interface on windows for a while now: it gives me the power I had with ksh and tools on Unix. It happily supports vi keybindings for searching/scrolling through history as well :-) I now do a lot of core work from that command line, even if it's ultimately to start a GUI app (it's much quicker for me to cd from the command line then start explorer than navigate via explorer). For those really annoying things, it's simple enough to create a script that emulates `grep` that takes -i and -r switches.

    It's brought back the ease to use the system that I missed from my Unix days (when having a few xterms permanently open was the norm; I now do the same with Powershell).

    For those dissing it and putting bash on a Windows box instead: that's not always going to work in corporate environment. Powershell comes pre-baked in so it's one less dependency to have to roll out, which is a win for deployment. For the same reason, I wouldn't insist on PS on Linux. However in a mixed-economy, you have the option to use whichever shell your comfortable with. For a Windows shop moving/experimenting with Linux, having the option to roll PS out means one set of deployment scripts can be ran on both systems (although deployment may be the least of the issues).

    I don't see this as a Linux vs MS vs. rest-of-world. It's nice to see the choice. No-one is forcing anyone to use it :-) As others have said, it gives you a lot of power, but so do shell scripts or perl, and it's easy to write unwieldy scripts in all of these.

  19. Patrick 17

    Bash isn't really comparable to Powershell. The closest Unix equivalent to Powershell that's in common use is Python. I script on Unix and Windows, Powershell is great for accessing Windows features easily and is a very modern scripting language. However, I doubt it'll take off on Unix or MacOS as most people won't want to learn it .. but it's nice to have another option available.

  20. Wensleydale Cheese

    Patch Tuesday

    So Patch Tuesday arrives on Mac and Linux?

    Methinks I'll pass.

  21. teknopaul

    binary pipelines

    A shell with binary object pipelines, merely shows what we already knew. That Microsoft do not grok the power and simplicity of text based protocols and that "everything is a file" approach.

    Very clever, but pointless if you grok unix.

    If you really want object pipelines in shell in linux use jq, without breaking the unix philosophy.

    1. h4rm0ny

      Re: binary pipelines

      >>A shell with binary object pipelines, merely shows what we already knew. That Microsoft do not grok the power and simplicity of text based protocols and that "everything is a file" approach.

      My inclination is to treat the above as humour. However, you continue on so I'm going to reply just in case it isn't. Text mangling is NOT "simplicity". Anything but. You have to change later steps in the pipeline when previous steps change. E.g. the output of `ls` and `ls -l` yield the same list of files but different textual output. So if the output is piped to other commands they must be cognizant of any changes. It's anything but simple, it's brittle and fiddly. If you pipe an array of file OBJECTS to the next tool, there's no text mangling required.

      And because an illustration is useful, here's getting the list of file owners in BASH vs. Powershell:

      Bash

      ls -l | awk '{print $3}'

      Powershell

      DIR | Get-Acl | Select-Object Owner

      Acl means "Access Control Layers" which is something anyone working with Windows at this level will know. Bash requires working with textual output. Powershell is all objects: Directory listing to get the ACLs to select the owner attribute. Very logical, very robust. The awk example will break if you try to feed it a file list from somewhere else (or even without the -l flag).

      Lets get more complex. Suppose I want not the current directory but a recursive tree. In Powershell it becomes this:

      DIR -Recurse | Get-Acl | Select-Object Owner

      Very simple change. I just add the recurse flag and the rest remains the same. Lets add one more tweak and have it select unique owner list:

      DIR -Recurse | Get-Acl | Select-Object Owner | Select -Unique

      All I did was pipe it to a unique filter. Simple.

      Now you might think that the Bash equivalent would be this:

      find ./ -exec ls -l {} \; | awk '{print $3}' | sort | uniq

      But you'd be wrong. Why? Because of the issue I talked about. `ls -l` is returning textual output, not an array of objects. And it throws in a summary line at the foot of each directory it traverses. My awk component which is downstream is now doesn't take care of everything. I need to add something to filter out certain parts of the text that have content. So something like this:

      find ./ -exec ls -l {} \; | awk '{print $3}' | grep . | sort | uniq

      The point is with text (which you think is simpler), you actually have more interdependencies between the components you're piping between than in Powershell where it's all clean objects.

      You have two components in the above (awk and grep) which are there purely to compensate for the fact that Bash is using text rather than objects. It's not simpler, it's anything but. And the more complex the script, the more brittle a reliance on text makes it.

      1. g00se

        Re: binary pipelines

        find ./ -exec ls -l {} \; | awk '{print $3}' | grep . | sort | uniq

        find -exec stat -c "%U" '{}' \; | sort -u

        You're welcome ;)

        1. Anonymous Coward
          Anonymous Coward

          Re: binary pipelines

          "find -exec stat -c "%U" '{}' \; | sort -u"

          Is that supposed to be more intelligible to a human? Because it really isn't. Powershell still wins hands down for intelligibility, simplicity and consistent syntax.

      2. RJG

        Re: binary pipelines

        One of the most reliable signs of a novice user on a linux system is that they use ls to generate lists of files and then use awk to parse out the bits of the output they actually want.

        And then complain about having to do that.

        in the above example, it is much easier to just get the information you want

        i.e.

        stat --format="%U" *

        1. thames

          Re: binary pipelines

          @RJG - He trotted out the exact same example a couple of years ago to attempt to show that Powershell was "superior", and I replied with a post showing him that the correct way to do it was with "stat". His reply to that was to waffle.

          If he's still using that same crap example now, it isn't because he doesn't know there's a proper way to accomplish the same job. It's much more likely that he spent many hours coming up with the most convoluted way of doing something in bash and isn't willing to part with it. Either that, or it's the example on the talking points script (as opposed to a shell script) from his marketing department and he's been told to use it.

          To repeat, he's already been told before that his example is bullshit and was shown how to do it correctly, and he read and replied to that, so he did read the post with the proper method. I would take pretty much everything else he's said on this subject with that in mind.

          Oh, and I benchmarked his example and one using "stat", and the "proper" way is dramatically faster than his method as well.

          I imagine that the reason that Microsoft is porting Powershell to Linux has nothing to do with any hopes that it will see widespread stand alone use. I suspect it has far more to do with supporting products that MS is porting to Linux such as MS SQL Server which may have some PS dependencies.

          There was an "object shell" for Linux some years ago (well before Powershell existed) whose name I can't recall, but it died from lack of interest. It simply didn't solve any problems that people actually had.

          1. h4rm0ny

            Re: binary pipelines

            And I'll say the same thing to you as on the previous occasion. You have missed the point. I could write a cmdlet called `stat` for Windows very easily that would do exactly the same. For ANY given example of a script I can create a program that will do that.

            I showed a comparison between pipelining in Bash and in Powershell and showed how object pipelining is simpler than text mangling. Using a program like stat does not illustrate text mangling. It illustrates a prepared macro that does the same. Which is trivially doable on Windows, as well. I'm comparing text mangling vs. objects not whether a sequence of pipelines can be replaced by a program. That is true of either OS.

            1. Anonymous Coward
              Anonymous Coward

              Re: binary pipelines

              No, it's called "using the correct tool for the job", not "make it look complicated to prove a point".

              If `stat` can't be used, then neither can `Get-Acl`.

              Many tools that are available to bash (as part of GNU/Linux) can be told to produce output in different formats, reducing the need to mangle text. Including `find`.

              You even neglected the -u option of sort, for extra artifice.

            2. Richard Plinston

              Re: binary pipelines

              > I could write a cmdlet called `stat` for Windows very easily that would do exactly the same. For ANY given example of a script I can create a program that will do that.

              Maybe, but for Linux there is usually no need to because programs have been there for years or decades.

              > Using a program like stat does not illustrate text mangling.

              No, it illustrates that text mangling is [often] not required.

              > I'm comparing text mangling vs. objects not whether a sequence of pipelines can be replaced by a program.

              Maybe, but you are ignoring objects vs. existing program where piping and mangling is not required.

      3. really_adf

        Re: binary pipelines

        find ./ -exec ls -l {} \; | awk '{print $3}' | grep . | sort | uniq

        Untested but should be useful pointers even if not quite right...

        POSIX:

        find . -exec ls -ld {} + | awk '{print $3}' | sort -u

        GNU find:

        find . -printf %u\\n | sort -u

  22. HmmmYes

    So many posters, so much bitching ..

    But no-ones picked the most obvious bitch - its version 6.0 FFS!

    Remind me what version is tcsh up to?

    My bitch is that, over the years, Ive moved a few Windows boxes that are around he office to PowerShell - I can be arsed with GUIs and the original pitch on PS was/is a good one - script stuff!

    However, I take my new script, which works on WS2088R2. Put it on an old box, which I do need, and it does not work - feature x not available.

    My choice is to rewrite the script or down load several 100Mb of .net update, which will sometimes not work as something else is out of sync.

    My big bitch about PS is that shell needs to be small, fast and useful.

    PS is large, slow and useful, in places. But cannot decide whether its a shell or a progranming language.

    1. ranger

      Whilst I'm not going to defend the uplift of versions, the primary cause of the version uplifts isn't because of new core language features or syntax changes: the last big change there was v4 (I think).

      But it's more that Powershell is really bash + binutils + netutils+{some other utils}. i.e., the cmdlets shipped tends to morph much more than the underlying language.

      Yes, there's an argument for splitting powershell into what's really core (i.e., the PS engine) and the cmdlets, and updating them separately. A case in point is some of the new networking cmdlets - there's no real reason these couldn't be made available in earlier versions of PS: I expect some of them are binary addins rather than PS scripts - so upgrading the entire package just to get a couple of new cmdlets is a nuisance.

      1. HmmmYes

        Its a nuisance s you have to download stuff over the interw.b

        Its fucking annoying when the computer is disconnected from the internet as its unpatched/out of support and only kept to verify an App wotks on an old Windows version - contract and all that,

  23. Doctor Syntax Silver badge

    It sounds like a perfect fit on Linux - with systemd.

  24. John Savard

    Ash nazg durbatulûk

    I'm surprised not to have yet seen a comment including the words "One Shell to rule them all", but I think it's perfectly sensible of Microsoft to introduce a tool that lets administrators of hordes of Windows machines also tell some Macs and Linux boxes in the same network what to do without learning too much about these strange other computers.

    It even helps to prevent migration!

    This in no way means that PowerShell has to be inherently superior to, oh, say, REXX, for example. Even if it does have scripting capabilities bash doesn't.

  25. DCFusor
    Gimp

    bash + awk + sed < perl

    Really, more need not be said.

  26. Anonymous Coward
    Anonymous Coward

    Powersploit

    Awesome!

    Does this mean my USB/HID flash drive running a Powersploit exploit can PWn Linux and Macs now too?

    https://github.com/PowerShellMafia/PowerSploit

    1. Anonymous Coward
      Anonymous Coward

      Re: Powersploit

      Most of those are Windows issues, not related to Powershell.

  27. Neil Alexander

    Bash vs. PowerShell nitpicking aside - I've used PowerShell plenty at work on Windows platforms, and I'm a big fan of how it can be used to automate many processes with scriptable access to hardware and software configuration, the operating system environment, network setup, Active Directory, etc.

    But all of these hooks are largely specific to Windows - it's not like I'm going to be able to bring a script that I wrote to do things on Windows and run it in PowerShell on macOS or Linux and expect to get the same results. In that case, why would I use it on non-Windows platforms when there are shells and tools for those platforms already available?

  28. jimbarfield

    I think people are missing the forest for the trees- really, as long as Microsoft is making inroads into the Linux ecosystem I consider that a very good thing.

    Sure Microsoft might be awkward but I feel it is a very good direction for open source and also Microsoft in general!!!

  29. Bronek Kozicki

    use case

    I read elsewhere that MS has added (not production ready yet) an ssh server to Windows. I am trying to guess what shell is that ssh going to make available for its users, could that be PS rather than cmd? If a Linux admin tried to do some remote administration of a Windows machine under ssh and landed in PS prompt, then perhaps it would help to be able to run (and learn the basics of) PS on a Linux machine? It wouldn't be great and it would not convince anyone to switch from bash or zsh, but it would serve the educational purpose, I think.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like