1. 19
  1.  

  2. 10

    Why use powershell on Linux? Don’t get me wrong, I like a lot of the ideas behind PS, and on windows systems I imagine it is invaluable, as it exposes all of the Windows APIs that were previously behind GUIs, but on Linux we have bash, and if you need more complicated stuff, you can use Python, with it’s excellent subprocess module, or ruby, or another language that you’re familiar with. Then you don’t have to deal with PS’s insanely wordy syntax.

    1. 6

      I think the article adequately explains why to use pwsh over bash, especially if you’ve written much bash. On the other hand, I think the article also seems less compelling at first glance if you have written a lot of bash, as I have, and as I’m sure you have. Experienced bash users are necessarily experienced in dealing with piping text between programs in lieu of a richer data model.

      I personally find shell scripts invaluable, and prefer them for system-level tasks over Python or Ruby. And I disagree about Python’s subprocess module—I think it’s clunky and verbose. Sure, pwsh has long command names, but for shell-like tasks it’s still more concise and clear than equivalent Python. And for interactive use, pwsh has many built in aliases similar to common UNIX commands.

      That all said, I’m hardly an experienced pwsh user compared to my bash, Python, or Ruby. But every experience I’ve had with pwsh has been pleasant and resulted in readable code. There’s only one reason I haven’t switched: pure momentum. I’m so used to bashisms that I have little reason to invest time in anything else. But if I could go back and choose where to invest my time—and if pwsh were available on Linux much earlier—I would choose pwsh.

      1. 4

        pwsh has long command names

        I think long command names are better than shorter command names. There is absolutely no reason that in $current_year we should use, document in, and most importantly teach (whether schools or documentation or books or blogs) what look like incantations to summon the prince of darkness.

        There was a time when cd was better than Set-Location. That has not been the case for decades. I’d argue if we are writing something that will be run more than once, you MUST write it in as verbose language as possible.

        1. 3

          There was a time when cd was better than Set-Location. That has not been the case for decades.

          There is an important case for shorter names: interactive use. sls is a lot easier to type than Select-String!

          1. 2

            I hate the fact that PowerShell is verb-noun, but with tab completion typing a short name that you’re very familiar with is a bit faster than typing a long well-namespaced name (e.g. String-Select) but it’s a lot faster to type a long well-namespaced name that you aren’t familiar with than it is to type the short one.

            For example, there’s a standard UNIX tool with a two- or three-letter name for printing a specific column of a stream and I never remember what it’s called, so I either spend a few minutes in man pages or just use awk and type more. Typing something like Column-Select would be 4-5 characters with tab completion and would save me a lot of time.

            I mostly use PowerShell for Azure admin things and I do that sufficiently rarely that the commands are never in muscle memory for me. Tab-completion works pretty well for helping me find things (though with noun-verb it would be much better).

            1. 2

              For example, there’s a standard UNIX tool with a two- or three-letter name for printing a specific column of a stream and I never remember what it’s called

              cut? I suppose I understand what you mean - but it does have mnemonic name - it allows you to cut out fields and columns?

            2. 1

              When writing things that I’ll need to write again, like api endpoints, or shell scripts, I favor shorter names. When writing functions I’ll be reading more times than I’ll be writing, I favor longer names. Coupling this guidance with a soft goal of lines under 80 characters, and I get what seems like a nice result to me.

            3. 1

              Powershell also has a bevy of shorter name aliases, designed for interactive use.

            4. 3

              Agree about shellscripts, but

              And I disagree about Python’s subprocess module—I think it’s clunky and verbose.

              Have you tried subprocess.check_call and subprocess.check_output? I ask because I used Popen for a long time and only last year thought to check for simple synchronous versions that are what I need a good 90% of the time.

              I do agree that Popen can’t really compete with the ease of bash piping, though; for large volumes of data, you need to use a subprocess.PIPE to process it (which you get for free with bash) and i’m not familiar with any idioms that make that painless.

              1. 3

                I kind of agree with the first response. subprocess is clunky, and frankly weird at times, but it’s really flexible, and for me, when I’m trying to structure data into arrays or dicts, I find bash even clunkier. Structured data is usually where I go from using bash to an actual programming language like python or ruby.

                1. 2

                  For me it’s just a matter of readability; something like grep foo file.txt | cut -d : -f 2 | tr -s ' ' is a lot more work in subprocess (or native Python).

                  This is like the old McIlroy vs. Knuth story, where Knuth had written a long Pascal program and McIlroy did the same with a fairly simple shell pipeline.

                  I think there was some library that tries to abstract a lot of the syntax around this, which might be a nice middle ground, and of course using Python brings many other advantages too.

                  1. 2

                    Right, and IMO it’s not entirely a subprocess issue; python generally solves different problems, and Popen doesn’t get in my way when I need something more complex than a short bash script. But It’s pretty hard to beat |, 2>&1, >>foo, &, etc. for concision, and sometimes I just wish it were as mindlessly easy to do pipes in python as it is to strictly evaluate a generator ([*foo]) or unpack a nested iterable (x, (y, *z) = bar). I’d probably set the threshold lower for when to use python vs. bash if that were the case.

                    arp242 mentions below that libraries exist for this sort of thing, and I’ve used plumbum for this in one project, but then you have to worry about portability, version management, bloat, etc, which is again a hindrance.

                2. 2

                  … And I disagree about Python’s subprocess module—I think it’s clunky and verbose.

                  I find it to be clunky as well, fortunately Python has Xonsh shell, which is pretty amazing ;-)

              2. 7

                The author should have just left out any discussion of existing shells on linux, as they clearly don’t have a grasp of the topic. It makes me suspect that they don’t really have much experience or expertise anywhere other than windows.

                1. 6

                  I hope PowerShell gets more traction on non-Windows platforms as it really is a fantastic shell, particularly given it’s now open-source. However, much of its power is inherently very dependent on PowerShell native commands; if you’re just calling native binaries which output text then a huge amount of its benefit is lost as you’re no longer dealing with an object pipeline. Once you’re back to parsing raw text output, frankly, the native *nix tools are superior (grep, sed, awk, cut, etc …).

                  PowerShell up-take on Windows was less of an issue, as coming from cmd and the sprawl of completely inconsistent and usually terrible native CLI tools, it’s not like there was an existing ecosystem anyone not suffering from Stockholm Syndrome actually liked. Also, investing in PowerShell was filling enormous gaps in Windows CLI support, rather than reinventing existing tools. But for *nix platforms, the tools do exist, and they are solid. The syntax may be inconsistent and arcane, but the tools are there.

                  This is a core rationale behind PowerShell Crescendo. Instead of a likely futile attempt to achieve parity with the existing tooling, leverage it by intelligently wrapping it. Whether it actually can achieve what it aims I have no idea …

                  1. 3

                    I think the biggest mistake PowerShell made was the name. It’s a great interactive scripting environment but it’s a fairly mediocre shell. The main job that a shell does is run external programs and that’s the thing that PowerShell is worst at. It also takes a long time to start (it needs a .NET VM and on my laptop it takes 15 seconds to start a new shell with the PowerShell modules that I’ve got installed), which is a deal breaker for something that you’d use for scripts that don’t run in the same process as the interactive environment (it’s not great for interactive use where opening a new Terminal tab is slow).

                    On the other hand, if everything that you want to do is supported natively by PowerShell and you never need to invoke anything external, it’s a nice environment. The second biggest mistake PowerShell made was to standardise verb-noun instead of noun-verb, which made tab completion less useful than it should be.

                    1. 2

                      It also takes a long time to start (it needs a .NET VM and on my laptop it takes 15 seconds to start a new shell with the PowerShell modules that I’ve got installed)

                      Are you using Windows PowerShell 5.1 or PowerShell Core (6+)? The performance difference is dramatic. On my fairly heavy profile with numerous modules:

                      PowerShell 5.1
                      Loading personal and system profiles took 5096ms.
                      
                      PowerShell 7.1
                      Loading personal and system profiles took 1509ms.
                      

                      Some code-paths are particularly pathological. I’ve seen instances where 5.1 takes 20+ seconds while 7.1 remains at <3 seconds.

                      1. 1

                        You made me curious, so I installed 7.1 and copied my profile.ps1 to the new location. It looks as if Windows PowerShell 5.1 is now faster, it takes only 1.5-2s to start. 7.1 takes 1.2-1.3s to start. Bash in WSL, including a very complex .bashrc and starting ssh-agent is still perceptibly faster than both, /bin/sh (a lightweight statically linked POSIX shell on FreeBSD, dash on Ubuntu) is significantly faster than either.

                  2. 4

                    The last time I explored using Linux powershell, none of the modules to communicate with an AD worked.

                    I use Linux machines that are joined to an AD, so being able to administer AD, IIS, etc from a Linnux machine without RDP would have been amazing.

                    1. 4

                      Coming from a job where I was a systems administrator in a Windows/Linux environment to my new job in a Mac environment I miss PowerShell a lot. I want to start using it on Mac, but the experience on Windows was fantastic, especially because of the deep system integrations. And prior to that job I was “Unix all the things!” so I definitely did not anticipate becoming a PS fan.

                      1. 2

                        (this got long, TL;DR: OO shell would be cool, but maybe simplicity is key, also check out jq!)

                        I like the idea of a “smarter” shell and while PowerShell is a good try, it’s definitely clunky and not a good one. It just feels so un-ergonomic (Get-ChildItem? is that to get a sub-process? what?). Also Perl’s implicit variables sprinkled throughout is just straight weird.

                        The idea of an OO shell that pipes objects vs just straight text would be cool, and jq kind of serves that purpose for me. One can map/filter/reduce json data in a pipeline, it’s awesome! Although adding methods to these objects would be pretty nifty…making filtering etc in pipelines even easier. But then again that makes it harder to understand. Looking up 6 different unix utilities (with great man pages) might be easier than looking up one or two custom object. But maybe that’s just because I’m so used to the standard coreutils.

                        Well this got longer than I thought it would be. Thanks for coming to my TED talk.

                        1. 3

                          The concept of item is defined as an object from a provider system, so a file or folder, a registry key, a row from an SQL database, etc. So Get-ChildItem just means children of an item. Commonly you would just write ls in the terminal if you want to invoke it.

                          If you want to do something related to processes, but you don’t know the command, I would highly recommend trying out gcm *process*. You’ll find that pwsh has a lot of aliases defined for common actions, gcm being aliased to Get-Command for simpler use. This command will list out every command that matches what you supplied as a search string, and since all commands in pwsh are so verbose, it’s rather easy to find a command that might do what you want.

                          And honestly, I have yet to find a unix utility with an actual “great” man page. At least in comparison to how damn good the man pages are in pwsh.

                          1. 2

                            In practice you don’t write the whole cmdlet, you just write gci.

                            1. 1

                              That’s my feeling about PowerShell as well. I like the ideas behind it. However, PowerShell the language is clunky, and on Windows, PowerShell the terminal environment is also clunky. Powerful in its ability to expose Windows APIs, and definitely better than cmd.exe or JScript/VBScript, but still…

                              I’m still not sure what a perfect programmatic shell should look like. There are some ideas coming from the ML/Haskell land that may be more promising than the OO approach.

                              1. 3

                                I dunno, the ISE[1] is pretty nice. PS does feel clunky for oneliners but it’s quite solid once you go above 1 line.

                                It’s still slow though. If I have to deal with multiple large textfiles I prefer to use Cygwin and cat/grep/Perl.

                                [1] integrated scripting environment