back to article Jeffrey Snover claims Microsoft demoted him for inventing PowerShell

PowerShell inventor Jeffrey Snover has aired some grievances about how his indispensable tool once got him demoted. The Microsoft Technical Fellow discussed the incident in a weekend Twitter thread that started when controversial investor Peter Thiel discussed the virtues of courage. "Courage is a key characteristic of future …

  1. Anonymous Coward
    Anonymous Coward

    And now Powershell is pretty much the rock of Windows.

    with the added twist that us poor *nix bods - looked down on for years - suddenly leapfrog the seasoned windows admins (who have said more than once that it's unfair) who ran a mile from the CLI.

    Almost everything you want to do in Windows Admin is now done with a PSE of some sort.

    1. Anonymous Coward
      Anonymous Coward

      Re: And now Powershell is pretty much the rock of Windows.

      "with the added twist that us poor *nix bods - looked down on for years - suddenly leapfrog the seasoned windows admins (who have said more than once that it's unfair) who ran a mile from the CLI."

      Not really. I have been a Windows admin for at least a couple of decades and always tried to script repeatable or automated tasks. Before powershell it was using CMD and 3rd party utilities for most of it.

      I am not militant either way and always just use the most appropriate tool for job.

      For quick one off changes to settings, use the GUI. For something you want to repeat or automate create a script. Sometimes use both. Use the GUI to make the change you want to automate, then dig into the system to see what it actually changed so you can script it.

    2. Abominator

      Re: And now Powershell is pretty much the rock of Windows.

      Still cannot properly delete files when the path is too long. Powershell is probably the best way, but even it regularly fails even with this.

      1. Anonymous Coward
        Anonymous Coward

        Re: And now Powershell is pretty much the rock of Windows.

        It does if you turn on long path name support:

        HKLM\SYSTEM\CurrentControlSet\Control\FileSystem

        REG_DWORD LongPathsEnabled = 1

        Works on all builds since 14393.

        Not sure why it isn't enabled by default now.

        Earlier builds, shorten paths using NET USE or SUBST or use robocopy.

  2. Anonymous Coward
    Anonymous Coward

    I would get it fired for inventing Powershell

    It's clumsy, slow, and with an ugly syntax.

    1. b0llchit Silver badge

      Re: I would get it fired for inventing Powershell

      It's clumsy, slow, and with an ugly syntax.

      So, a recipe for success at the MBA level decision tree then. No wonder we are all suffering.

      1. pimppetgaeghsr

        Re: I would get it fired for inventing Powershell

        MBAs are members of the mangaerialist class, how dare you criticise them, do you even know how much it costs their parents to enroll them on those MBA courses!!?!

        1. Zippy´s Sausage Factory
          Devil

          Re: I would get it fired for inventing Powershell

          Of course we don't. But unless there's an easily reusable KPI formula for it in one of their college course books, neither do they.

      2. Abominator

        Re: I would get it fired for inventing Powershell

        It's basically immediate mode .NET

        Fairly gross.

    2. wolfetone Silver badge

      Re: I would get it fired for inventing Powershell

      So I started out with Windows, then moved away to Linux, and now where I am while I use Linux 100% of the time but I need to provide support to Windows machines. Most of the time the PowerShell is helpful in doing that.

      I think you are right that the syntax isn't great. It feels, sometimes to me, that commands given are like a weird pirate copy of the usual DOS prompt you used to get with Windows. It doesn't feel that intuitive compared to the language you use on the Linux CLI.

      But it's miles ahead of what was possible with DOS, and the fact that even with it's ugliness it allows us to actually do things in Windows now. And that makes it rather pretty.

      1. Alan Bourke

        Re: I would get it fired for inventing Powershell

        There hasn't been a DOS prompt in Windows since Windows ME. There is CMD.EXE, which supports DOS commands.

        1. Anonymous Coward
          Anonymous Coward

          Re: I would get it fired for inventing Powershell

          Isn't there a 'pedant' icon? Why yes, yes there is!

          1. Anonymous Coward
            Anonymous Coward

            Re: I would get it fired for inventing Powershell

            Is that the one with an inverted triangle, black and furry, like a minge ?

        2. John 104

          Re: I would get it fired for inventing Powershell

          @Alan Burke

          25 down votes from people who have no idea what they are talking about...

          To you down voters:

          cmd ported many DOS commands for ease of use. It is most assuredly NOT a DOS prompt.

          As for Powershell syntax, well, its based on .NET, so that might help you a bit with understanding why it is the way it is. And, Linux shell is no peach either... It comes down to what you are well versed in and spend time using more than anything else.

          1. Contrex

            Re: I would get it fired for inventing Powershell

            As someone who started with MS-DOS 3.30, and welcomed the cmd.exe language that came with Windows NT4 and 2000, I feel your pain.

          2. VoiceOfTruth

            Re: I would get it fired for inventing Powershell

            I often get a lot of down votes myself from people who don't know what they are voting on. Fight the good fight.

            Even when you explain it they will down vote you.

          3. Anonymous Coward
            Anonymous Coward

            Re: I would get it fired for inventing Powershell

            > people who have no idea what they are talking about

            Or conversely, who know the subject well enough to understand colloquial talk.

            1. Anonymous Coward
              Anonymous Coward

              Re: I would get it fired for inventing Powershell

              "colloquial" is a polite term for "utter bollocks", I take it?

          4. John Brown (no body) Silver badge

            Re: I would get it fired for inventing Powershell

            "And, Linux shell is no peach either"

            Which one? There are so many to choose from :-)

          5. eldakka
            Headmaster

            Re: I would get it fired for inventing Powershell

            > And, Linux shell is no peach either...

            Mr "It is most assuredly NOT a DOS prompt." pedant, I can be pedantic too:

            There is no Linux shell.

            Linux is a kernel.

            There are executable programs that can be run by the Linux kernel that give you a shell, Bourne (sh), Korn (ksh), C shell (csh), Bourne-again (bash), tcsh, ash, and more.

            You don't like the shell that has been installed by the Linux distribution that you are using? Install a different one. There is even Powershell for Linux if you prefer powershell syntax over the more common default shells used on Linux distributions.

            1. ABehrens

              Re: I would get it fired for inventing Powershell

              Go home, Stallman, you're drunk again.

              1. eldakka

                Re: I would get it fired for inventing Powershell

                > Go home, Stallman, you're drunk again.

                Maybe you should read - and understand - the entire thread for context before embarrassing yourself?

                Remember:

                Better to remain silent and be thought a fool than to speak and to remove all doubt.

                - various unproved attributions including Abraham Lincoln and Mark Twain amongst others.

                ETA: But I never take this advice myself, so yes I am a hypocrit.

          6. werdsmith Silver badge

            Re: I would get it fired for inventing Powershell

            @John 104

            <sigh/>

            Yes we know. Does it matter?

          7. Steve Aubrey
            Stop

            Re: I would get it fired for inventing Powershell

            "Shakespeare wasn't written by Shakespeare. It was written by somebody else named Shakespeare."

      2. Steve Davies 3 Silver badge

        At the risk of being downvoted to hell

        (you need to be an old-timer to get this)

        Bring back DCL.

        Compared to Powershell it was pretty good.

        1. UCAP Silver badge
          Pint

          Re: At the risk of being downvoted to hell

          From one old timer to another - have an upvote. And a beer.

        2. Paul Mitchell
          Facepalm

          Re: At the risk of being downvoted to hell

          Anyone remember JCL, the language where comments are significant (shudder)?

          1. Warm Braw

            Re: At the risk of being downvoted to hell

            If you mean this JCL, it's still very much alive.

            I'm not sure what you mean by significant comments, but if you use JES3, the control statements begin with //* - the same characters that introduce a JCL comment - which means you can't include JCL comments that begin with any of the JES3 commands in your virtual card deck. You'll be pleased to know that JES3 is on its way out, though JCL seems here to stay indefinitely.

            1. cschneid

              Re: At the risk of being downvoted to hell

              JES3 is now supported and enhanced by Phoenix Software.

            2. bluesxman

              Re: At the risk of being downvoted to hell

              Been over 20 years since I was near JCL so don't have any well formed memories, but it sounds more like it doesn't actually have "comments" but just ignores control statements that don't have a valid command ... so you could perhaps standardise on something like

              //* COMMENT: actual comment text

              <shrug>

            3. doublelayer Silver badge

              Re: At the risk of being downvoted to hell

              I hate that comment structure on principle. I've seen some languages intended for education that take a real language, usually C, C++, or a derivative, and bolt on a compiler that does something based on comments. I won't name those languages to avoid drawing undeserved attention to that monstrosity. Every language must have at least one comment syntax that is guaranteed not to be treated as code and should be as clear as possible.

          2. chuckamok

            Re: At the risk of being downvoted to hell

            Yes, I was learning COBOL, which made sense. Also C and Unix with bourne shell, which also made sense.

            Then they showed us how to run COBOL programs in JCL. Nothing makes sense there. That took my brain offline from learning COBOL.

            Powershell reminds me a little of JCL, it makes a tad more sense, but hard to bludgeon your way forward like you can in *nix shells.

        3. Warm Braw

          Re: At the risk of being downvoted to hell

          Bring back DCL.

          I still have the manuals. I keep them handy on a low shelf in case I need to reach a higher shelf.

          1. cosmodrome

            Re: At the risk of being downvoted to hell

            > I still have the manuals. I keep them handy on a low shelf in case I need to reach a higher shelf.

            Oh, it's a buddhisht set of manuals?

        4. Mr Larrington
          Thumb Up

          Re: At the risk of being downvoted to hell

          I'd upvote that ^^^^ twice if I could.

        5. Frumious Bandersnatch

          Re: At the risk of being downvoted to hell

          > Bring back DCL

          Rexx here, please.

        6. Tim_the_Unenchanter

          Re: At the risk of being downvoted to hell

          DCL is still alive and kicking, though it is showing its age. There isn't much you can't do with DCL...

      3. Pirate Dave Silver badge
        Pirate

        Re: I would get it fired for inventing Powershell

        IMHO, Powershell's "ugly" comes from the fact that, on the surface, large portions of it look like "programming" as opposed to "scripting". But once you get down into the nitty-gritty, the facade falls away, and it's just scripting, or perhaps "scripting++", since MS did a pretty good job of pre-canning a lot of simple functionality for us (sorting, searching, reading/writing files, etc) that makes the old DOS prompt look absolutely spartan. I'm still doing about 40% batch files and 60% powershell - some things ARE still easier to do in a batch file, especially where there's an existing utility (Robocopy, icacls, etc) that does most of the heavy lifting.

        1. Anonymous Coward
          Anonymous Coward

          Re: I would get it fired for inventing Powershell

          Ah, but have you figured out how to do datastructures in a batch script?

          It's sorta possible, but a horrible idea, and is based on the fact that "set" REALLY doesn't care what the variable name is. So:

          set structure.array[12]=3

          creates a variable called "structure.array[12]" and sets it to 3.

          1. Pirate Dave Silver badge
            Pirate

            Re: I would get it fired for inventing Powershell

            eh, I know how to use "classes" as data structures in PS5. Does that count? There is some annoying syntax to it that I usually forget and have to copy-paste from earlier scripts.

            Some things were soooo easy in Pascal... <sniff, wipes tear>

      4. david 12 Silver badge

        Re: I would get it fired for inventing Powershell

        actually do things in Windows now.

        Using the same COM objects that were used by vbscript to do the same administrative tasks.

        It's right there in the name: "shell".

        1. emfiliane

          Re: I would get it fired for inventing Powershell

          Buddy, I hate to tell you this, but COM was taken out back over a decade ago. Powershell can only work off .Net Assemblies, nearly all of which completely dispense with the archaic complexity of COM. There are a handful of interops specifically for speaking to legacy COM, but having to use it is incredibly rare in a modern system.

          1. Cliffwilliams44 Silver badge

            Re: I would get it fired for inventing Powershell

            But you can still use a COM object in PowerShell. It's just not a straight forward.

    3. VoiceOfTruth

      Re: I would get it fired for inventing Powershell

      In comparison to UNIX that may be so (I demur about it being slow as I don't know). But Powershell for Windows is very good indeed, it's very useful.

      I can imagine the people who demoted him sitting around nursing their right click muscle memory while drinking their decaffs... but but but he's making it more like UNIX. Isn't the whole point of Windows to have a window? Sip. More gluten-free biscuits, anyone?

      1. Denarius Silver badge

        Re: I would get it fired for inventing Powershell

        dont you all recall the old saw " No good deed goes unpunished" ? Yes, I was mostly ksh for its speed over bash but in last job wrote production powershell scripts by reading manuals. I did love the *nix toolkit so much more after that, but one has to work with whatever toolkit is on hand.

      2. eldakka
        Flame

        Re: I would get it fired for inventing Powershell

        > Isn't the whole point of Windows to have a window?

        Something that always triggers me on any stripe of GUI (windows, X, whatever) are 'windows' that:

        1) Can't be resized;

        2) can't be moved;

        3) prevent you from bringing to the foreground a window that is 'under' it that it 'spawned' from (modal? windows).

        Each of those items seems to defy the whole point of using a 'windowing' GUI. The amount of times I've opened a 'config' window and think, "oh, what I need to configure depends on information that is on the window under it, but I can't see that information because I can't move/background this fsck'ing window that I need to put data into that is on the now-hidden window under it that I can no longer access".

        I don't care if the developer thinks there's no point in being able to resize a window. It's a window, I should be able to resize it, maybe there's some use case they hadn't thought of, or the message it's to display is stupidly long and can't fit in the fixed-size window, whereas stretching it a bit might make the message intelligible? Barring any specific security considerations (maybe it's meant to hide some other information until some security check is passed), if it's a window, I should be able to move it, resize it, bring to the front another related window, grrr.

        1. yetanotheraoc Silver badge

          Re: I would get it fired for inventing Powershell

          "... a window that is 'under' it that it 'spawned' from (modal? windows)"

          This.

          Windows the OS has forgotten how to do windows the GUI element. Windows that continuously steal focus as their parent program loads. Windows that don't respect the z-order and can't be sent to the back. Child dialogs that pop-under instead of -over. I recently wrote a script that includes a dialog "look for the password dialog (from other program) behind the other windows". Maybe MacOS and GNU-Linux have similar issues, but so far I haven't run across them.

          I have a love/hate relationship with Powershell. When I script Windows in (four) other languages I tend to be very wordy, e.g. using long camel-case variable names, lots of small functions, etc. Yet somehow I find Powershell's wordiness too tedious. The saving grace is that sometimes Powershell can accomplish in one .NET pipeline what would take a fairly large VB Script (for example) to do the same, _and_ Powershell handles all the edge cases effortlessly, whereas in VB Script I usually end up with a comment "doesn't work as desired in case of xyz".

    4. Plest Silver badge

      Re: I would get it fired for inventing Powershell

      Agree BUT it's light years ahead of DOS batch and in certain areas, ahead of *nix scripting and even things like Python. Try working natively with JSON or XML files in DOS batch or *nix script without any extra utils, can't be done. Work with ZIP files without a ZIP util on hand, PoSH wil do that natively.

      I find PoSH to be almost like SQL ( I was a DBA for 20 years ) , you must always be aware of the size and structure of what's coming down the pipe, if it's in the wrong format or too big, go back and keep the pipeline flow "lean, mean and clean".

      I see so many PoSH noobs making the mistake of chucking bucket loads of crap down the PoSH pipe and then moaning it's complete rubbish, no you simply need to undertstand it better to make it dance.

      1. Doctor Syntax Silver badge

        Re: I would get it fired for inventing Powershell

        The essence of the Unix approach is that the shell provides the control structures with very few builtins. All the heavy lifting is done by other programs; that puts them all on an equal footing, including any you might care to provide yourself.

        1. Denarius Silver badge

          Re: I would get it fired for inventing Powershell

          some simple shells, yes. ksh93 had many built-ins that made running scripts about 40 times faster on multithreaded hardware and OS. Yes, I profiled traditional and built in equivalent scripts to get that figure on sizable data

    5. itzumee

      Re: I would get it fired for inventing Powershell

      My understanding was that PowerShell syntax was designed to make it easier for Bash-heads to pick up PowerShell?

    6. Mr Dogshit
      FAIL

      Re: I would get it fired for inventing Powershell

      Ugly syntax for sure.

      You'd think equals would be =

      Nope. It's -eq

      Greater than >

      No. -gt

      1. sev.monster Silver badge
        Happy

        Re: I would get it fired for inventing Powershell

        Meanwhile in Bourne shell...

        if test "$x" -gt 9 -a "$y" -eq 10; then

        And yes, this works in Bash.

        1. runt row raggy

          Re: I would get it fired for inventing Powershell

          all the text after test and before the semicolon is areguments to the program test, not bash syntax. there's plenty wrong but that's not it. also, test does also have an = operator.

          1. emfiliane

            Re: I would get it fired for inventing Powershell

            You're missing that point that Powershell syntax was derived directly from *nix/sh test syntax.

          2. sev.monster Silver badge

            Re: I would get it fired for inventing Powershell

            I am very aware test has a string equality operator. I used numbers and numeric comparison operators here because I was illustrating the similarities between Bourne shell syntax and PowerShell, as well as the "ugliness" they both share. What emfiliane said is correct.

            And what I was illustrating here was not specifically targeted at Bash—hence why I specified "Bourne shell" as I did. Following UNIX/POSIX nomenclature, Bourne shell does not include any built-in comparison operators (other than not operator !) and relies fully on the return value of programs, such as test. Unless you want to compile your own program to do what test already does or forego all of its functionality, there is simply no other way.

            If you really want to be pedantic, it's POSIX syntax, and not explicitly Bourne shell syntax. Doesn't change the point.

      2. Doctor Syntax Silver badge

        Re: I would get it fired for inventing Powershell

        You'd think equals would be =

        Nope. I'd expect it to be an assignment.

        Greater than >

        Nope, I'd expect it to be a redirection of output.

        The first is a universal issue in languages, differentiating between an equality test and an assignment. The latter isn't universal but it becomes an issue in a language that has to deal with redirecting data flows.

        1. Pirate Dave Silver badge

          Re: I would get it fired for inventing Powershell

          I thought assignment was ":="?

          <ducks>

      3. Anonymous Coward
        Anonymous Coward

        Re: I would get it fired for inventing Powershell

        Yeah, there are a bunch of thinks in Powershell that seem weird like that. But there seems to have been a guiding principle behind it. Try first to resolve ambiguities, where conflicts exist, go with solutions that have been used in other languages/shells, etc.

        I feel like it's not worse than perl and onboards WAY more stuff than the stock *nix shell (unless you include stuff from Awk and Sed, which are NOT par of the shell or shell scripts but can be called from them)

        The way you work with stuff that deals with multiple objects in Powershell never sat comforatably with me. I still have to fiddle with the syntax whenever I doing something like a directory update or bulk user import. Too many things change from working with single records when you wouldn't always expect them too. Like figuring out which switches work outside or inside the ForEach, and which things you can set without one.

        1. sev.monster Silver badge
          Facepalm

          Re: I would get it fired for inventing Powershell

          One of my biggest gripes in PS is trying to write code that can handle single objects or arrays being passed to it. It's the cmdlet/module authors' faults for not always sending one or the other, and there are cmdlets in the standard library that do it. Thankfully it is easy to resolve, but if you don't know what might be sending what before writing something, it can be very painful to debug later.

        2. Anonymous Coward
          Anonymous Coward

          Re: I would get it fired for inventing Powershell

          "it's not worse than perl"

          Not exactly a ringing endorsement, considering perl is the one with the obfuscation contests resulting in code that looks like line noise...

          1. Denarius Silver badge

            Re: I would get it fired for inventing Powershell

            not seen sendmail config file then ?

            1. Anonymous Coward
              Anonymous Coward

              Re: I would get it fired for inventing Powershell

              Been there, done that, have the gray hairs to prove it...

        3. martinusher Silver badge

          Re: I would get it fired for inventing Powershell

          The clever bit in 'ix' shells isn't the actual shell but the #! first line of any text script that directs execution to the shell or scripting language of your choice (or should I say "the language that best solves the problem you have"?).

          1. sev.monster Silver badge

            Re: I would get it fired for inventing Powershell

            And if you want to be pedantic, shebangs are implemented entirely in the kernel and are syntactically unrelated to the resultant shell :)

      4. Kristian Walsh

        Re: I would get it fired for inventing Powershell

        I suspect you don’t do much shell programming. Consider this bash snippet:

        X=009

        test $X = 9

        ... should that return true or false? It returns false, because '=' compares text. There’s a difference between lexical comparison (characters must all match) and value compare (parse to numeric, then numeric results must match), and numeric comparison is what -eq, -le, -gt and company do on the unix `test` command ([ is an alias for test, chosen to make shell-scripts a little more readable).

        Powershell is similar, but you first need to know that PS is a typed runtime (like Python). The equivalent code:

        set X 009

        if ( $X -eq 9 ) { echo "true" }

        will report true, because X is a number. Change that initial assignment to be a string, and the comparison now fails.

        set X "009"

        if ( $X -eq 9 ) { echo "true" }

        If you want to force integer comparison, you can cast the operand:

        set X "009"

        if ( [int]$X -eq 9 ) { echo "true" }

    7. sev.monster Silver badge
      Boffin

      Re: I would get it fired for inventing Powershell

      When it first came out, I would have agreed with you. In truth I avoided it for years because "cmd just worked" and "the syntax sucks" and "it makes no sense why they're doing this" and "it's slow as hell".

      But then the versions continued to roll out, more modules got developed, the infrastructure got better, and speeds improved greatly. And now we have the largely open-source and multi-platform .NET Core and PowerShell Core, with perfectly acceptable performance and a bevy of useful features. Being able to easily script against .NET Framework/Core objects (or just straight up write in CLR languages and load them at runtime) is such a huge boon, especially when Windows is so tightly integrated with it. There essentially isn't anything you can't do with PowerShell on modern Windows, and it far outshines the capabilities and cruddy syntax of cmd.

      Anyway, if you want to talk about bad syntax, let's honestly and objectively take a look at Bash, or really Bourne/POSIX shell in general, and all their ilk. You mean to tell me x="hello world"; echo "${var%world}" is self-evident without already knowing what it means? Or the fact that you can't put spaces around the = when assigning a variable, which has tripped up every newbie? Or the other hundred non-trivial hurdles you have to work around to make a good script? The grass is not always greener on the other side. Even in Windows-land, ask any veteran sysadmin and they will tell you every which way cmd syntax sucks, and how inflexible and error-prone it is; it even shares some of the problems that Bourne shell does, like assigning variables.

      Fact of the matter is PowerShell is a hell of a lot more expressive than its competitors, even if the syntax is still a little wonky after all its revisions. I'd take it over cmd any day, and if I didn't know anything about *nix shell and weren't already used to it, I would probably take it on Linux too.

      1. Anonymous Coward
        Anonymous Coward

        Re: I would get it fired for inventing Powershell

        Exactly this. As somebody who had used CMD for years, I didn't take to PoSH at first when Exchange 2007 came out.

        However, once you get to grips with it, see how it treats everything as an object and follow some best practice guidelines (don't use aliases in scripts, strongly type all your variables, etc) it lets you do powerful stuff at the prompt and build very readable scripts than do pretty much anything with the system.

        Something that in most other shells will take multiple lines and need you to parse the output of one command to feed into another becomes a simple one liner where you can just pipe one CMDLet into another.

        Some CMDLets can be wordy, but many have aliases and tab completion makes their length a non issue anyway. When you use the full CMDLet names in script it makes them very readable.

        Always remember: Filter left, format right!

    8. Graham Cobb Silver badge

      Re: I would get it fired for inventing Powershell

      I've never really used Windows for anything serious (my history is RSX->VMS->Linux, when not working on embedded systems) but I am impressed with Powershell for its ability to work with objects and collections as basic building blocks.

      The ability to pipe around objects, instead of just character streams, along with primitives to allow constructs like "for each" and "case" switching based on class in a standardised way would be very useful improvements to bash.

      1. AndrueC Silver badge
        Meh

        Re: I would get it fired for inventing Powershell

        ..plus you can call into .NET assemblies. We've used it to knock up test harnesses and to write simple utilities to support our .NET applications. Sometimes it's quicker than writing yet another .NET application.

        There are times it can thwart though. At a recent meeting we got stuck trying to get the value of a variable passed to an external application. We could echo it to the screen but couldn't figure out how to get it expanded in a command line. It being the end of the day was probably a factor in that but it's a pretty trivial thing to have defeated half a dozen software developers.

        1. sev.monster Silver badge

          Re: I would get it fired for inventing Powershell

          At work I use it to set desktop background color by embedding C# directly in the script.

          Add-Type @'

          using System;

          using System.Runtime.InteropServices;

          namespace BGInfo {

          public class DesktopColor {

          [DllImport("user32.dll", SetLastError=true)]

          private static extern bool SetSysColors(int cElements, int[] lpaElements, int[] lpaRgbValues);

          private static readonly int[] elements = {1}; //COLOR_DESKTOP

          private static readonly int[] colors = {3873552}; //[System.Drawing.ColorTranslator]::ToWin32([System.Drawing.Color]::FromArgb(0, 16, 27, 59))

          public static void Update() {

          SetSysColors(elements.Length, elements, colors);

          }

          }

          }

          '@

          [BGInfo.DesktopColor]::Update()

          1. AndrueC Silver badge
            Happy

            Re: I would get it fired for inventing Powershell

            Taking you all the way from a script to a user32.dll method. I don't know whether to applaud PS for that or run away screaming :)

            1. sev.monster Silver badge

              Re: I would get it fired for inventing Powershell

              Gotta admit it lives up to its name :)

      2. W.S.Gosset Silver badge

        Re: I would get it fired for inventing Powershell

        > to allow constructs like "for each"

        Actually, this is shell's behaviour for "for": it just iterates thru the defined list.

        You can create a numeric progression list via shell expansion if you want the original "for", but I don't think I've ever needed to do that for shell tasks.

    9. NoneSuch Silver badge

      Re: I would get it fired for inventing Powershell

      "It's clumsy, slow, and with an ugly syntax."

      It's all of that with inconsistent switches from command to command and version to version.

      It also allows MS to stop developing GUI. Why right click and select an option when you can type a 400+ character PS command that can bork your domain instantly.

      1. sev.monster Silver badge
        Childcatcher

        Re: I would get it fired for inventing Powershell

        There is STILL no admin interface for Microsoft Bookings. It has been years, and STILL the only way to get access to someone's Bookings account is to manually add yourself with Exchange cmdlets. It's absolutely infuriating.

        That aside, you should try PS Core. It cleans up a lot of the nonsense since it is essentially a separate product to mainline Windows-bundled PowerShell based on the .NET Framework. Later versions of Windows will likely include it by default once they get feature parity.

        1. AndrueC Silver badge
          Meh

          Re: I would get it fired for inventing Powershell

          Several years ago I was writing software that required me to test against several enterprise backup packages. One of them had a UI that appeared to have been generated by parsing the output of the command line help for tar. Even down to some options effectively being duplicated.

          I can't remember which one it was now. Like most of its ilk it was complicated and unwieldy to use.

    10. Cliffwilliams44 Silver badge

      Re: I would get it fired for inventing Powershell

      PowerShell is only slow if you do things that make it slow. Yes, the pipeline is convenient but over use or inappropriate use of the pipeline will cause serious performance issues.

      Other performance issues are not really PowerShell but the Windows services you are interacting with. i.e. Active Directory, Exchange, SQL server etc. Unfortunately these services can only be interacted with using Windows PowerShell, which is considerably slower than PowerShell Core.

  3. Roger Kynaston
    Meh

    powershell command missing

    When on earth will they come up with an equivalent of du?

    full file system and you want to find the culprit in *nix

    ls /some/dir | while read line

    do

    du -sh $line

    done

    I once found the code in powershell but it was so ugly I couldn't deal with it. It is good to have powercli on linux though so I can take snapshots etc. So, on balance I suppose it is a good thing.

    1. FIA Silver badge

      Re: powershell command missing

      du -sh /some/dir/* | sort -h

      1. FIA Silver badge

        Re: powershell command missing

        Powershells not tooooo much more verbose, although I've omitted the sorting which I expect would add a fair bit. :)

        Get-ChildItem c:\some\folder | ForEach-Object { Echo $_.Name ; Get-ChildItem -Recurse . | measure-object -property Length -sum }

        1. G40
          Alert

          Re: powershell command missing

          Excellent example thank you. The brevity and elegance of Bash shines. And what are those bizarre PS constructs to the right of the pipe?

          1. Anonymous Coward
            Anonymous Coward

            Re: powershell command missing

            Never underestimate how easy it is to make "different" = "worse".

            And PS uses autocomplete, so far less typing than you'd think.

          2. sev.monster Silver badge
            Boffin

            Re: powershell command missing

            The brevity of *nix is because all the commands were abbreviated out of necessity. The real star here is du/POSIX and not really Bash—just imagine what you'd have to do if du didn't exist!

            Looking at the example, it's actually not correct. Fixing it you get the below output. (Unfortunately pre and code tags are being horribly butchered by our vulture overlords, sorry.)

            PS C:\> Get-ChildItem C:\Users\me | ForEach-Object { Echo $_.Name ; $_ | Get-ChildItem -Recurse | measure-object -property Length -sum }

            ...

            Desktop

            Count : 63

            Average :

            Sum : 10194386

            Maximum :

            Minimum :

            Property : Length

            ...

            Downloads

            Count : 26

            Average :

            Sum : 429328707

            Maximum :

            Minimum :

            Property : Length

            ...

            You're wondering what the syntax is about. We can break it down.

            Get-ChildItem C:\Users\me |

            Pipe in all children of your user folder. In PowerShell, all pieces of data are .NET objects, and every item returned by Get-ChildItem is fully formed. This is unlike other scripting languages that might return a string for the filename (e.g. Bash). This gives you a lot of flexibility.

            ForEach-Object {

            Here we iterate over the objects sent thru the pipe. This is similar to piping to read in *nix shell, but over objects instead of strings.

            Echo $_.Name ;

            This writes the item name to output; echo is an alias for Write-Output. (And its use tells me that the OP may not be very well versed in PS...)

            $_ | Get-ChildItem -Recurse |

            This is my change. Here we are sending the current object in the loop (in PS it's $_ for ForEach-Object) into Get-ChildItem. OP's example used . which used the current directory. We are using a pipe here instead of -InputObject or using -Path $_.FullName because it's shorter and should be faster.

            Aside about loops: You can specify the variable if you use the foreach statement, but you can't use statements (easily) in pipes. ForEach-Object is a "cmdlet" and is able to process pipe input and send output, so that's why it's used here. You can also use -PipelineVariable xyz if the thing you are piping from is a cmdlet, and this will provide the variable xyz to the next scope in the pipe.

            measure-object -property Length -sum

            This consumes every object sent down the pipe, reads each Length value, which is in this case the file's size and provides a sum.

            ...But this example also isn't very good. It looks nothing like du output. We can make some changes to better emulate du and make it more "PowerShell"-y.

            PS C:\>gci C:\Users\me -pv x|%{$_|gci -r -ea 4|measure Length -s -ea 4|select Sum,@{l='Filename';e={$x.Name}}}|sort Sum -d

            Sum Filename

            --- --------

            429328707 Downloads

            10194386 Desktop

            2265 Searches

            I tried to make it as compact as possible, and the output looks good; here is what it would look like if el Reg didn't murder it. Funny enough, this result from SO that I looked up afterwards does essentially the same thing, though I am making use of some newer language constructs (like -PipelineVariable via the -pv alias). If you are curious I can explain this one too, but it will take more time. It also is not truly faithful to the du experience, as it only shows the toplevel children including files, and does not give a grand total for the toplevel directory. Modified to do that, you would get something like this:

            $x='C:\Users\me\Downloads';(gci $x -ad -r -fo -ea 4)+(gi $x)|%{$d=$_;$_|gci -r -fo -ea 4|measure Length -s|select Sum,@{l='Filename';e={$d.Name}}}|sort Sum -d

            Sum Filename

            --- --------

            429329118 Downloads

            288174446 folder 2

            7952775 folder1

            4964601 test

            I know it looks esoteric as hell, but keep in mind I am trying to keep it short, which means using all the alises and shortcuts I can. I also must stress, we are essentially re-implementing du here, and that's why it looks so much more verbose. If du or an equivalent existed in PowerShell, it would be as easy as:

            du | sort

            which is no more verbose than in *nix. But as far as I can see there is no equivalent.

            If you wanted to have an experience like that, you could take the snippet I wrote above and put it in a function/cmdlet in your PS profile, which is the PS equivalent to Bash profiles. Though, I would honestly recommend to not use it, since it's not optimized at all, and you are relying on whatever PS implementation you're using to properly handle all the duplicate objects :)

            1. Anonymous Coward
              Anonymous Coward

              Re: powershell command missing

              Good writeup.

              I create functions for a lot of "foreign" commands and other useful stuff in profiles.

              I put them in a module that I import in the "all users all hosts" profile on all the domain machines in our organization so I have them available on any machine. Only gets annoying when I use external machines that don't have the module and I have forgotten that a command I use all the time isn't available.

          3. doublelayer Silver badge

            Re: powershell command missing

            "Excellent example thank you. The brevity and elegance of Bash shines."

            No, it doesn't. What shines in the bash example is the power of the du command. Delete that from /bin and try making bash do it for you. The result will be a lot longer and uglier than the PS commands written above.

            There is also an alternative in PS: get the source for du, compile it, and put it on your path. You can use the one that Git for Windows has. Cygwin probably has a usable one too. Then all you have to do is pipe its output to a sorter of your choice. The thing that gives you all the power, clarity, and brevity is a platform-independent executable designed for the task. Bash does not deserve the credit for that.

            1. Kristian Walsh

              Re: powershell command missing

              The bash solution becomes ugly very quickly once your needs diverge from "results sorted by directory size". The PowerShell version, on the other hand, is trivial to adapt to sorting by any attribute of the system.

              You can also trivially adapt the PS version to give you sizes, sorted by most-recently modified directories, or excluding directories that have not changed since a given date. Try that in a bash one-liner if you really want to learn the darker corners of bash (but really, don’t do it: complex functions belong in scripts, not one-line alias macros)

              Lest I be accused of fanboyism, I should mention that I don’t use PS very much: I overwhelmingly write scripts in bash (or more accurately, the subset that’s approximates the original Bourne Shell - a habit formed from writing for embedded systems using dash and other lightweight shells). But I’m not some kind of idiotic zealot who thinks that just because something is from Microsoft, it’s inferior to whatever came from Unix. The reason I don’t use PS because it’s not well supported on Linux, where I do most of my scripting; and on Windows, its default commands are all different to what I know from Unix.

              But if you’ve ever had to parse the crap emitted by linux tools like ip, you'd wish that Linux had something like PowerShell’s object-stream approach to pipelines.

              Making the most common Linux tools produce key-value output (even if it has to be in a lousy format like JSON) would be a start, but that requires cross-project collaboration, which is something the Linux world has proven to be very bad at.

        2. Fat Guy In A Little Coat

          Re: powershell command missing

          Gci instead of Get-ChildItem and ? instead of ForEach-Object would cut down on verbosity there.

          1. Anonymous Coward
            Anonymous Coward

            Re: powershell command missing

            It would and I will often use aliases at the prompt, but using full CMDlet names in scripts is a best practice and makes them much more readable.

          2. sev.monster Silver badge

            Re: powershell command missing

            For-EachObject is % and Which is ?

            1. blaisem

              Re: powershell command missing

              The ? is short for where-object, and the other alias alternative is simply where. Then your filter scriptblock looks almost like SQL, except your comparison operators are different.

              1. sev.monster Silver badge

                Re: powershell command missing

                I use the unaliased form of ? so little I actually forgot what it was aliasing.

        3. Alan_Peery

          Re: powershell command missing

          That lists each subdirectory, but doesn't total the size of each of those directories properly. I suspect it's giving the full disk usage of c:\some\folder because the totals are the same for each child directory.

          cd I know it's behaving in your example, but here's my output:

          PS C:\Users> Get-ChildItem C:\Users | ForEach-Object { Echo $_.Name ; Get-ChildItem -Recurse . | measure-object -property Length -sum }

          apeery

          Count : 1946

          Average :

          Sum : 38742310694

          Maximum :

          Minimum :

          Property : Length

          defaultuser0

          Count : 1946

          Average :

          Sum : 38742310694

          Maximum :

          Minimum :

          Property : Length

          fred

          Count : 1946

          Average :

          Sum : 38742310694

          Maximum :

          Minimum :

          Property : Length

          Public

          Count : 1946

          Average :

          Sum : 38742310694

          Maximum :

          Minimum :

          Property : Length

          Directory: C:\Users

          Mode LastWriteTime Length Name

          ---- ------------- ------ ----

          d----- 08/02/2022 09:46 apeery

          d----- 04/05/2021 16:15 defaultuser0

          d----- 03/05/2022 12:56 fred

          d-r--- 06/05/2021 00:04 Public

        4. blaisem

          Re: powershell command missing

          nix users will only see cmdlet names as an unnecessary waste of space, because they live in a world where all the commands are 2-3 letters that everyone understands because they've seen them for decades. Might as well use aliases for the sake of comparison:

          gci | % {@{ $_.name = (gci $_ -R | Measure Length -Sum).sum}} | sort [Keys|Values]

          You can sort by Keys (filename) or values (filesize). It's not bad for a native implementation without a dedicated standalone like du. If you wanted to make it really pretty and do it properly then you could treat yourself to a dozen kilobytes of code in your profile to write a proper function. Depending on the skill of the implementation, the flexibility and intuition of it would quickly outstrip what du offers.

      2. Peter Gathercole Silver badge

        Re: powershell command missing @FIA

        Whilst you've shown how terse UNIX like OSes are, I would argue that none of your example actually shell, apart from constructing the pipeline.

        Du is a separate program. Sort is a separate program. All the shell has done (and with this example it could be pretty much any shell) is spawned the du and sort, and connected them with a pipe. Even the pipe itself is not a feature of the shell, but of the underlying OS.

        Too many people cannot differentiate what is actually part of the shell, and what is separate programs. That is one of the strengths of the UNIX way, but it can lead to lazy thinking by people who don't fully understand the thinking.

        I once taught an IBM course, (IX22 maybe? It's a long time ago) called "Advanced Shell Programming". In it, the material included tools like awk and sed (but not Perl, as that was yet to be mainstream), but I was at pains to point out when I was teaching that these were really not part of the shell. I made sure that the students understood the difference. I actually set an exercise for them to really perform a task completely in the shell. I can't remember exactly what it was now, but it was much easier using external programs, but still possible in the shell.

        I did manage to slip in some examples of ksh co-processes, however, at least one of which was actually useful!

    2. Dan 55 Silver badge

      Re: powershell command missing

      Or, before you've run out of space, install tree.

    3. Pirate Dave Silver badge

      Re: powershell command missing

      "When on earth will they come up with an equivalent of du?"

      I was just looking at this last week to find a way to log directory sizes on the file server. There is a du utility somewhere, maybe from SysInternals. But it turns out, to get the disk usage of really large directories, the "fastest" way to do it in Powershell is to use Robocopy (with the /L switch) and parse the output. Crazy as hell, yeah, but true. Takes like 8 lines of PS code and bazinga! Robocopy must have super-magical Jedi code in it because it hands-down beat the shit out of every other method I tried, by a large margin.

      1. yetanotheraoc Silver badge

        Re: powershell command missing

        "super-magical Jedi code"

        Old fashioned Win32 API, instead of modern .NET. But I suspect the biggest difference is that to code in Win32, you had to know _everything_. To code in .NET, you can get by without knowing much. Powershell is the apotheosis of .NET, more so than C#.

        1. Pirate Dave Silver badge

          Re: powershell command missing

          I figure it's more than just Win32 vs .Net, since I assume that SysInternal's "du" command is Win32 as well. But Robocopy thrashed it and usually only took a mere fraction as long to go through a large 300,000+ file directory (seems like I recall Robocopy took 9 seconds, du took around a minute). My un-wizardly guess is that Robocopy puts its fingers down into some low-level NTFS stuff directly, or as directly as is possible under an NT kernel.

      2. blaisem

        Re: powershell command missing

        Robocopy is pretty unbeatable for performance in filesystem parsing. You can even call .NET methods and abandon PowerShell syntax entirely, but Robocopy will still win with embarrassing ease.

    4. Fonant
      Thumb Up

      Re: powershell command missing

      ncdu

    5. Anonymous Coward
      Anonymous Coward

      Re: powershell command missing

      "When on earth will they come up with an equivalent of du?"

      Quite a while ago. Latest version is here if you want it:

      https://docs.microsoft.com/en-us/sysinternals/downloads/du

  4. karlkarl Silver badge

    Job control or Tmux is greatly needed for PowerShell.

    Currently you need to open up multiple SSH sessions to the same Windows box like it is some sort of multi-user DOS from the 90s again.

    1. sev.monster Silver badge

      You can do job control, but it's nowhere near as clean as with *nix shells, i.e. just put & at the end. Here is an older but still relevant high level discussion, and here is the official documentation. Once you get used to it it's fine, but it's still a bit more to type and manage.

      At least it's better than cmd, which has no such functionality.

    2. Pirate Dave Silver badge
      Pirate

      I used PoshRSJob for a script a couple of years ago, it allows "parallel" processing for stuff like pinging an entire subnet (that's what I'm using it for anyways...). I didn't dive into it as a learning experience, just figured out what I needed to do for what I was doing and moved on. In my case, it made a helluva difference in how long the script took.

  5. hammarbtyp

    One of the interesting parts of the thread was the total toxic culture due to a particular VP. It explains a lot and MS at the time, and I wonder whether the culture of stack ranking was part of it?

    Certainly he seems to have a VP who was scared in upsetting his bosses, and was not willing to fight for their team. Basically a culture where innovation was frowned upon and discussion was stamped our.

    It pretty well explains a lot of MS products at the time

    1. Doug 3

      How Microsoft operates internally reminds me of how Trump operates. If you are not making Windows look good then you are Fake News( bad for Microsoft and bad for Windows ). No doubt PS acted too much like the *nix commandline even if more in intent than execution. Linux is bad because it is not Windows and anything which validates something other than Windows makes Windows look bad. Trumpanze thinking and this thinking has been instilled in Microsoft management ever since their split from IBM.

      1. Kristian Walsh

        Your use of the present tense is odd in that post, given Microsoft’s current championing of PowerShell—and, for that matter, Linux—on Windows today. This is not the 1990s anymore.

        And Microsoft never had any relationship with IBM they could “split” from apart from being a vendor of DOS, and a development partner in OS/2 - both in the 1980s: anyone managing then retired long ago.

        The rot in the 1990s was what happens to any dominant player in a market: gaining share becomes more difficult, so management decides instead to rent seek, and adopt defensive positions to block competition (we’re seeing this with Apple on mobile). Of course, these tactics are contrary to the needs of customers, and can sow a long-lasting poison that damages the chances of any genuinely good product that comes from the company later. As an example, Windows Phone was the most techically advanced mobile SDK, with amazing low-resource performance, and I believe that it would have been a success had it not come from Microsoft, with all the baggage and industry distrust that that entailed...

        Microsoft, like other successful companies, also attracted the bullshitters. I worked for Apple in the 1990s, and we used to say that the only good thing about working for a dying company (which it was then) was that the kind of MBA-but-no-intellect manager-class tended to avoid us when choosing a place to inflict themselves upon. Instead they flocked to Oracle, Netscape (heh), Microsoft and Sun, who were all on the up, and thus offer a low-risk environment for their inept ideas. (Not to say we didn’t have home-grown assholes, but nobody tried to bring in morale-destroying “new ways of working”)

        1. blaisem

          Windows champions PowerShell today, but they are also always looking for GUI options to supersede it. Modern PowerShell is like the fallback for the relatively small power user base. The native Windows version hasn't been touched since 2015. Windows Server 2022 won't commit to PS Core either, so it will be at least 10 years if not more shipping a version with some noticeable performance issues. I feel it's the best framework for a shell experience out there by a long shot, yet its potential could be pushed so much more than being a sideshow.

          But reading the comments here reminds me that it's difficult to engage new audiences. PS's potential makes it most ideal as a shell for developers and programmers who can take advantage of coding; meanwhile, all these developers and programmers spent their freshman year in college in Bash and have stayed there for the past however many decades. To them, the mystifying moment you first try to tackle a nix commandline with arbitrary 2-3 letter commands, opaque single-character parameters, and inconsistent syntaxes unifying the built-in functionalities has completely vanished from their memories. The equivalent proficiency in PowerShell would take half the time or less, but that could still mean several months of consistent use.

          Then, among the Windows userbase, all the Windows admins are always looking for "The right tool for the job" -- basically an executable or interface that does everything for them with a click or single command. I can't tell you how many I have come across that can barely put a script together. And so Windows keeps investing in the handholding measures as there is little incentive to push the potential of the language.

          PowerShell is unfortunately awkwardly positioned in Windows.

    2. Doctor Syntax Silver badge

      There's a saying that software reflects the organisation chart of the company that produced it. Perhaps it reflects the corporate culture as well.

  6. chivo243 Silver badge
    Unhappy

    Just be a dick

    and you'll go far is the moral of the story for VPs, GM's etc. I was a GM for a while, and couldn't shit on everybody, glad I got out.

  7. trevorde Silver badge

    No good work goes unpunished

    Implemented a 'find & replace' for a product I worked on many years ago and was disciplined for my efforts. The company was owned by IBM and I wasn't following the procedures.

  8. oldtaku Silver badge
    Devil

    He should feel kind of ashamed

    Yes, it's what you do admin things in on Windows, but Powershell was such a lost opportunity. It was obviously designed by someone who'd never used *nix and therefore made all the same mistakes as its shells but learned nothing from some of the great design decisions. In an ideal world Powershell would have been an object oriented tcsh (or zsh, bash, whatever your oshi is), like C# improved on everything Java, but instead it's just another clumsy mishmash of inconsistent design and baffling omissions. It's better than DOS BAT, I'll give it that.

    1. Dave_A

      Re: He should feel kind of ashamed

      It was designed in the era where Ballmer ran Microsoft and Linux was a threat to the bottom line not a universal fact of IT life & included Windows feature.

      Stuff like Ansible wasn't really a big thing back then either, and if it was see-above on mid/early 2010s MS and nix-y tools....

      Yes, they should have gone with a Bash derivative and exploited the existing knowledge base..... But the same argument could be made for NT way back when (NT being mutant VMS because the Alpha and PowerPC were going to give Intel a run for their money (oops))....

  9. spireite Silver badge

    Poeershit?

    I hate it with a passion...

    Maybe I'm old, but I find it horrible, clunky... I just can't get on with it

    1. chivo243 Silver badge
      Go

      Re: Poeershit?

      Maybe I'm old, but I find it horrible, clunky... I just can't get on with it

      Is there room in that boat?? I'd like a ticket please!

  10. beekir

    Scriptable .NET Components

    PowerShell's magic is two-fold. One is the way it redefines the traditional sense of input & output streams. The other is the way it provides scriptable access to the enormous world of .DLLs and .NET components.

    1. Version 1.0 Silver badge

      Re: Scriptable .NET Components

      "Fire and brimstone coming down from the skies! Rivers and seas boiling! Forty years of darkness, earthquakes, volcanoes! The dead rising from the grave! Human sacrifice, dogs and cats living together... mass hysteria!" -- The Ghostbusters explain why not to buy or use any Microsoft products. (an ASR sig).

  11. Anonymous Coward
    Anonymous Coward

    Serious question

    From a non Windows user:

    Could it be described as something of a cross between a Bourne shell and a D-Bus client?

    1. KSM-AZ

      Re: Serious question

      I'd go more with, someone decided to create a language that would (eventually) do everything you could possibly ever want to do with a system or database by adding 'modules' and roll it into a big giant mess that makes PERL look good. This is similar to what IBM did when it went from OCL on the 34/36 to QCL and then onto compiling CL for 'performance' and now I can have input forms on my CL! Every time I've tried to do something with powershell I've had to get a module, or something, and then everything is an object, so often the result you get is not what you expect, or requires further parsing or... It's just very darn inconsistent from function to function, and then the function you found that does what you want is only for Azure, not a domain controller, and ...

      Sorry, but I'm not overly impressed with powershell to this day. dumping write-hosts's to see things in loops often fail to reveal actual object content that breaks somewhere else, blah, blah. Working with objects is great as long as you have a thorough understanding of each and every object you use. You are a maze of twisty little objects, all different.

      I think shells and shell scripting should really be GLUE logic for weaving things together. If you want to get serious write some real code, in a language designed to accomplish the task, and use your shell to weave it all together.

      And I'm happy to help tar and feather the idiot that decided names should be quoted and escaped by default in a directory listing on modern unix breaking scripts. (ls -1 | ...). The minute you make a 'shell' that is all things for all people, what you end up with is a 'thing' that is a necessary evil for a lot of people.

      Of course opinions are like assho...

      1. Anonymous Coward
        Anonymous Coward

        Re: Serious question

        I think much of the criticism of Powershell comes from either:

        1. People who have never used it "because its Microsoft"

        2. People who have used it a bit and become disillusioned as it is unlike other shells they have used.

        I was not keen on it at first, but after having a few "Aha!" moments, I now could not do my job without it.

        There are a few simple tricks that work wonders (like using get-member to fully understand all the properties and methods that belong to an object) and major performance tweaks like filter left, format right and not using += on large arrays.

        Best advice I can offer is to actually read some of the various primers and best practice guides out there (both official and unofficial). They will give you some key understandings that you probably won't get by just diving in and playing around.

        Being able to grab a collection of objects and cycle through them all with a foreach one liner lets me get results in seconds that using older methods could have taken hours.

        Other methods would normally mean bending the output of one command into the input the next one needs. With Powershell, just send it all down the pipeline, then worry about formatting the output at the end.

      2. Peter Gathercole Silver badge

        Re: Serious question @KSM-AZ

        I've upvoted you for your comments about quoted filenames in ls, but I think you'll find that if you pipe the output from ls into something else, it doesn't quote the file names at all (try ls | cat).

        This means that it is unlikely to break scripts.

        You can also set an environment variable QUOTING_STYLE=literal to remove the quotes,

        But like you, I can't stand having the quotes, And I also can't stand the arrogance of the developers who change it, and apparently ignored all of the complaints.

        I'm interested in hearing which modern UNIX has adopted this. I guess if you're using GNU coreutils on a Sun box you may pick this up (but I wonder whether the native Solaris 'ls' does it), but I don't believe AIX has implemented this. And there aren't many other UNIXes around anymore.

        1. _andrew

          Re: Serious question @KSM-AZ

          I've been using Unix for more than 30 years, and at first I had no idea what this comment and its parent was talking about. So I googled, and discovered something new. Thanks to you both! The gist is:

          https://www.gnu.org/software/coreutils/quotes.html

          which describes how GNU broke ls in 2016, apparently in order to make it easier to cut-and-paste with a mouse.

          I'm especially interested that it has apparently been a thing for eight years, and even though I use Linux and the gnu utilities quite often, they are not my "primary" unix environment, so "hmm, that's odd" hadn't percolated to the level of working out what was wrong, until now. As explained: the decoration is only applied if stdout is the terminal, not a pipe.

          Regarding the comment "aren't many other UNIXes around anymore": well, there's still macOS and the BSDs, which is where I do most of my command-line work.

          1. Peter Gathercole Silver badge

            Re: Serious question @KSM-AZ

            Not spotted my posts before, have you.

            When I talk about UNIXtm, I'm talking about Genetic UNIXes, i.e. ones that were licensed and developed from AT&/Bell Labs., or UNIX that has been through the verification process from The Open Group.

            MacOS does not use a UNIX kernel. It uses a kernel derived from the Mach kernel, with the BSD toolset grafted on top. One of the versions a while back was certified as a UNIX, but Apple did not keep up with the process. So yes, macOS could be a UNIX, but in my purist miind, it's only UNIX-like.

            The various BSDs are derived from an archaic version of UNIX that not only diverged from mainstream UNIX back in the 1970's, but legally does not contain any UNIX code not inherited from UNIX Edition 7 (and proved in a famous case between AT&T and the Regents of the University of California).

            There has been no BSD UNIX-like OS that has received UNIX branding.

            I admit that *BSD* OSs are very much UNIX like, having been using UNIX since 1978, and having used BSD since when it was shipped as an add-on tape for a Bell Labs. But there is no way it can be legally called UNIXtm.

            So, the last UNIXes standing are AIX, which is sort of still being developed, and Solaris and HPUX, both which are not (no new hardware driving development). Everything else has fallen.

    2. Dave_A

      Re: Serious question

      No.

      It's more like 'what if we built a command line interface around a hodgepodge of VB and JavaScript'....

      It's A-LOT more functional than cmd or the old VBscript, but it's got no connection to the (much more established) UNIX command line, as it's a product of early-2010s Ballmer-run MS not the 'we make our money in the cloud & bundle a Linux environment with Windows' 2020s version....

    3. Dave_A

      Re: Serious question

      One more thing... It's truly amazing for managing VMWare hosts.... As opposed to pointy-mc-clicky in a web browser...

      New MS released it for Linux so you can actually have a Windows free world, and still use pwsh for managing ESXi virtual-appliances (which use photon Linux as their base OS)....

    4. sarusa Silver badge

      Re: Serious question

      Nope. If it had been a cross between bourne shell and anything it would have been much better than the mess it actually is.

  12. skeptical i

    la plus ca change ....

    "Courage is a key characteristic of future leaders and previous employees." -- J. Snover

    "'Controversial' only means 'this will lose you votes'. 'Courageous' means 'this will lose you the election'!" -- Sir H. Applebee

  13. Nitromoors

    You don't have to like it to appreciate it.

    Last job I did after 50 years of being involved in most things IT was to write some PS scripts to read a MySQL database via ODBC for people holding certain posts and create as needed accounts in the online Active Directory and apply SharePoint folder permissions depending on the post. Email the new user and the sysadmin, also remove persons or change perms as the posts changed.

    More recently I was asked to change the data source to a REST API returning JSON when the database moved off prem. Easy and quick.

    Try doing that in bash or cmd.exe.

    It was about 30 lines of functional code by the time it was nice and maintainable for a non programmer sysadmin.

    I could have done it in:

    PERL - Ugh. Very powerful and I loved it when we were both young, but sadly the romance faded.

    .Net 300 lines

    c# 450 lines

    PYTHON never did get the hang of those white spaces and tabs and far to prone to getting messed up by said sysadmins.

    1. yetanotheraoc Silver badge

      Re: You don't have to like it to appreciate it.

      "...create as needed accounts in the online Active Directory ... Try doing that in bash or cmd.exe."

      dsquery / dsget / dsadd / dsmod would do that in cmd.exe, probably even easier than powershell. Funny though, they pipeline objects just like powershell does.

      https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc732952(v=ws.11)

      I grant that sending an email is not so easy in cmd.exe. And for SharePoint, powershell is The Way.

    2. _andrew

      Re: You don't have to like it to appreciate it.

      It pays to keep in mind that the "traditional" unix tools are all about flat/regular files embedded in a hierarchial file system. They don't do things like JSON queries well, but that's OK: there wasn't any JSON when they were pulled together. *

      Today there's jq, and we can get on with pulling information out of JSON files in simple one-liners as the gods of REST intended.

      (*): Call me old-fashoined and a slave to my favourite tools, but I've never met a JSON file that I prefer to the obvious alternative collection of flat multi-column files. Still, it's all the rage, and there's likely no going back. "Self-documenting", they say, as though that was a virtue.

  14. Phones Sheridan Silver badge
    Mushroom

    Internet goes boom!

    Woke up to a Jeffrey Snover tweet, about a The Register article about a Jeffrey Snover tweet!

    https://twitter.com/jsnover/status/1523992647454498816?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Etweet

  15. A2Wx8
    Meh

    I love it but I hate it

    You can do some awesome stuff with PowerShell, but sometimes making it do that awesome stuff is an utter nightmare. What a cmdlet returns isn't always documented well, or at all. What repository the cmdlet is in and what permissions are required, etc. etc. PowerShell ISE on Windows is a tremendous help for all that.

    But then you get it all working and the power to automate some very tedious or complex tasks is fantastic.

    The simple can sometimes be brutally cumbersome, and the complex can be a breeze with it.

  16. Tim_the_Unenchanter

    if the right libraries existed, Python would be a really good choice for a scripting language (and they may very well exist, I haven't looked into using it as a shell / script replacement.)

  17. EricTheKool

    PowerShell background

    I was on the same team as Snover when he came up with the idea of PS. The really important part was the decision higher up to wrap all of the Windows API in .Net classes. That allowed a .Net utility like PS to be able to access all of the .Net class library. Lots of us, myself included, saw the need to have a consistent and accessible way to interact with Windows. I programmed for decades in C and C++ and it is really difficult to get code correct in those languages. Memory leaks, wild pointers, buffer overflows, oh the joy goes on!

    The MS review process at the time was notoriously fickle with managers forced to assign review scores on a curve. I hadn't heard that he was demoted but he wouldn't have wanted to broadcast that kind of thing. As the saying goes "The beatings will continue until morale improves!"

    One of the original PS designers wrote a book on the design process. He went into great depth on the discussions and decisions about the design choices that were made. Unfortunately I'm forgetting his name and the name of the book. Perhaps someone can contribute that.

    1. blaisem

      Re: PowerShell background

      Cool, thanks for sharing a point of view from that time :)

  18. ScissorHands

    "Shell of an Idea," the Untold History of PowerShell

    https://powershell.org/2020/01/book-shell-of-an-idea-the-untold-history-of-powershell/

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