16 ms·

Microsoft’s PowerShell Core Offers Cross-Platform Automation

112 points by el_duderino 9y ago

mpweiher 9y ago
Conceptually, Powershell is really cool. But in practice, I find it both cumbersome and very, very slow. For example: marcel@vger[Downloads]time pwsh -c 'ls' >/dev/null real 0m0.824s user 0m0.636s sys 0m0.213s marcel@vger[Downloads]time sh -c 'ls' >/dev/null real 0m0.011s user 0m0.003s sys 0m0.005s marcel@vger[Downloads] That's around a factor 80. Hmm. OK, startup costs, JITs hard time, yadda yadda. But it's not just that. For example I found a simple dir -r to be more around 50x slower than the equivalent ls -lR And so on.
- SwellJoe 9y ago
  On top of this, writing PowerShell feels like programming rather than scripting. I know that's sort of ambiguous, but PowerShell is astonishingly verbose compared to bash, or sed/awk, or Perl. PowerShell may be a better programming language than bash, but the times I wrote some, it took me a lot longer (maybe mostly because of my own familiarity with bash) and the resulting scripts were bigger (which I think is unavoidable). I just don't find PowerShell fills a niche I need to fill, even though it seems to be really powerful and designed by smart people. I guess if I worked on Windows it would fill a niche since it has hooks into the system that are harder to reach in other non-MS languages.
  - rb808 9y ago
    Sometimes I just want to open a shell and run an exe. With powershell you need to run a command which runs the application. I gave up after that. https://stackoverflow.com/questions/1673967/how-to-run-an-exe-file-in-powershell-with-parameters-with-spaces-and-quotes https://stackoverflow.com/questions/1673967/how-to-run-an-ex...
    - randomString1 9y ago
      What's wrong with .\example.exe? Or .example.exe, .$exampleWithPath for PS1 files? Just examples that I see in the wild
      - rb808 9y ago
        Didn't work for me, I think you have to prepend with a & so & notepad.exe Which isn't complicated I agree but annoyed me.
        AnIdiotOnTheNet 9y ago
        What version of Powershell are you using? Just typing "notepad" is enough to launch it. The problems with powershell and executables only really come in to play when argument passing, where some escaping is necessary.
        rb808 9y ago
        3, we still have win7 at work.
        joeyaiello 9y ago
        You can download and install PowerShell Core 6 completely side-by-side with Windows PowerShell 3.0. We even have a portable ZIP you can drop down wherever: https://github.com/powershell/powershell/releases https://github.com/powershell/powershell/releases
        Arnavion 9y ago
        The only reason to use iex is if the thing you're trying to execute is not directly the name of the process. So you need & for `&'notepad'` and `&$string_variable` but not `notepad`
    - gecko 9y ago
      That's not quite correct (and neither is that StackOverflow answer). If you want to execute the EXE stored in a variable or whatnot, then yes, you need `&`, which I think is borrowed from Perl. But otherwise, the rules in PowerShell are the same as a Unix shell: if it's in the PATH, just type the command name (with or without the .exe); otherwise, use the full path.
  - wvenable 9y ago
    My biggest complaint with PowerShell is that it's unnecessarily inscrutable -- filled with Bash-like and Perl-like syntax and semantics without the legacy to justify it. I wish writing in PowerShell was as easy as writing C# but instead it's almost as bad as writing Bash scripts. It's not good for programming or scripting. There are so many good ideas in PowerShell but it's wrapped in a weird body.
    - sgtmas2006 9y ago
      I love it for both programming and scripting. It's probably not the best option a lot of the time, but I still find myself going back to write things in PowerShell. I don't find myself running into any of the issues you bring up in my experiences. Everyone has something specific they prefer, though. I find coming back to and reading foreign PowerShell to be quite natural, and rarely taxing if formatted well. I can't pinpoint what I like so much about it either... It just draws me in well. It does devolve in readability when trying to squeeze out every drop of speed, though. IPC is what I find to be the most challenging for me in PoSH, but I'm not sure if that's due to incompetence.
    - darksim905 9y ago
      As a Syasdmin, Powershell is a scripting dream: it has tab completion for the commands and the switches. I don't feel like I have to guess or look at man pages to figure out why there's a -s and an -S. The help pages are usually written for human consumption by comparison. Saying that it is 'unnecessarily inscrutable' is quite hilarious - have you seen some Linux commands & the lack of output they give? Powershell, if anything, ins extremely verbose & is clear in when something goes wrong. At least, it doesn't insult you like Ansible tooling with the ^ YOU MADE A MISTAKE HERE BUT WE CAN'T BE CLEAR WHAT IT IS
      - mattmanser 9y ago
        We have all of that in C# without the rediculously bad syntax. It's such a shame powershell didn't come 2 years later, I feel like they'd have had no choice but to use C# instead of inventing a new language.
  - AnIdiotOnTheNet 9y ago
    Powershell has short aliases (and you can define your own too) for the most frequently used commands, and I find the process of reformatting text output between commands to get them to pipe to each other and not choke on formatting differences more cumbersome and time consuming than any extra verbiage added by powershell.
    - contextfree 9y ago
      Most of the aliases use a consistent naming pattern too, which I appreciate.
    - smacktoward 9y ago
      But this can cause other problems. An example would be the way that Powershell for a long time aliased the Invoke-WebRequest cmdlet to both 'curl' and 'wget'. This was supposed to be a convenience feature, but it broke all sorts of scripts that were written to use "real" curl or wget because Invoke-WebRequest didn't accept curl or wget option parameters (oops). They've fixed this in recent versions by shipping actual curl binaries, but it's a useful illustration of how just aliasing popular shell commands to their Powershell alternatives isn't necessarily helpful.
      - contextfree 9y ago
        invoke-webrequest has a "native" short alias too: iwr. I like these native aliases because they use a consistent pattern of abbreviations for verbs and nouns, e.g., the same "i" for invoke is used in icm = invoke-command, iex = invoke-expression, ihy = invoke-history, etc.; then if you look at the nouns in one of those others (since invoke-webrequest is the only "webrequest" cmdlet), they're also consistent, e.g., gcm = get-command, shcm = show-command, trcm = trace-command.
  - voidmain0001 9y ago
    I concur. For me personally, PowerShell's dependency on the .Net Framework just makes me write what I need in C# and then deploy to clients using GP. In my environment the client computers don't have a consistent .Net version which follows that they don't have a consistent PS version installed either. For a recent data collection program it was faster and easier to write it in C# and target .Net V2 then to fiddle with PS, and its execution policy https://stackoverflow.com/questions/4037939/powershell-says-execution-of-scripts-is-disabled-on-this-system#4038991 https://stackoverflow.com/questions/4037939/powershell-says-...
    - mistermann 9y ago
      What kind of C# are you writing, is it a compiled exe you're distributing or is there some way to run C# script on windows? I've done almost nothing with PowerShell due to the brutal syntax, would love to use a nice language like C# or Python for the control structure (logic, looping, etc) and then just calling out to PowerShell when needing to execute a function. Seems like that should be a possibility, although passing data through may be problematic.
      - Someone1234 9y ago
        csi.exe runs C# interactively as a script.
      - rusanu 9y ago
        You don't need to 'shell' out to call PoSh. You can host it yourself, see https://msdn.microsoft.com/en-us/library/dn569260(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/dn569260(v=vs.85).a... Passing data is quite easy, both ways, is just C# objects. This can be convenient when faced with one of those 'Powershell only API' features.
      - voidmain0001 9y ago
        It's a compiled binary (PE). I've read through numerous books on PowerShell and I don't see its value in comparison to using any other .Net language. All namespaces in PowerShell are available in C#/VB/blah so why deal with the annoyance of ensuring that the client has not only the required version of .Net Framework/Core installed, but also the PowerShell interpreter version too? Perhaps it's because PowerShell doesn't require a compiled binary so it can be modified and run without an extra step, and it allows for easy add-ins with the cmdlet interface.
  - systems 9y ago
    I just to comment on this by saying That whatever space powershell fills on windows its not a niche .. not a niche at all I agree with you, powershell is powerful and I guess benefit from being new .. it has amazing uniformity and amazing discover-ability Anyway, I was saying, powershell fills automation on windows, it is THE automation tool on windows and has been for a while, there is hundreds of commands that you can you to manage and deploy and update almost anything important on windows This is not a niche, not a niche at all .. it is as far from niche as i can think of And now that it is being ported to other systems, it had the potential to be THE automation tool for many organization that have mixed environments So you see, when it was primarily windows, it was not a nice, again because automation on windows is not a niche .. now imagine it beyond even windows Powershell is about automation, not scripting, and not just the command line ... it is really about automation Instead of following steps, you automated with one script ..or possibly a small GUI app
    - SwellJoe 9y ago
      I think you and I merely disagree on the meaning of "niche" in this context, rather than on facts about usage of PowerShell. I was simply saying that PowerShell doesn't serve a unique purpose in my environment that isn't better served by other languages or shells. "Niche" was short-hand for, "This language is particularly well-suited for this task or set of tasks", and I wasn't (intentionally) saying anything about its popularity. All programming languages have a niche where they are strong. It is not a way of saying, "This language is obscure or not used a lot." It's a way of saying, "For the things I do, I can rule it out, because I don't need to do the things this language does better than others." From what I can tell, scripting (or, "automating", if you prefer that term) Windows is PowerShell's niche. I don't need to script Windows, so I don't need PowerShell. In short: Saying PowerShell doesn't fill a niche I need to fill is not an insult to PowerShell or a statement about how popular it is. It's merely saying I don't find it suits my needs in my environment (which contains no Windows servers).
    - mattmanser 9y ago
      As a programmer who knows powershell to an extent, I still make cruddy little console apps rather than piss around with powershell. That's where powershell failed abysmally.
  - JeffreySnover 9y ago
    PowerShell was designed to provide a very wide dynamic range of capabilities from interactive actions to simple ad hoc scripts to more formal programming. The goal was to have a single tool that admins and programmers could share to create and manage systems where they could pick how formal they needed to be to solve the problem at hand and can simply modify (vs replace) it as the solution need to be by more people or more production scenarios. Jeffrey Snover [MSFT]
- nailer 9y ago
  Powershell 6 halved my start times from 1.5s to 720ms. However some things will always be slower, aince powershell does more for you than bash does. Compare productivity from not scraping to consider the tradeoffs.
- maxxxxx 9y ago
  I have tried PowerShell multiple times and hated it every time. They either should have gone with a language like bash or gone straight to C# as scripting language. Powershell is that weird in between that does nothing well. I know a lot of people love Powershell though.
  - taysix 9y ago
    Agreed. I tried automating an installation of some software in powershell. I kept getting different errors on different windows machines depending on what version of Windows they were on and what features they had installed. Ended up rewriting the whole thing in C#. Runs everywhere I need it to and zero issues.
- joeyaiello 9y ago
  Our filesystem provider could definitely use some performance work, and we're discussing redoing it at some point in the next minor version release or two. Personally, for quick interactive stuff, I just `ls` when I'm sitting on a non-Windows machine. My finger muscle memory just does `ls -al` and `rm -rfv` when I'm sitting on a Linux box. But if I need to do some heavy sorting/filtering, I'd much rather save the minutes wrestling grep/awk/sed/xargs than save the minutes on execution (or the hours on having just done some operation based on some grep/awk/sed/xargs work that I didn't properly test).
- cm2187 9y ago
  I am more of a windows guy and I have been trying to automate more things with powershell in the last month and I must say that compared to its equivalent in linux it is an absolute dog's breakfast. A few examples of the absurd things I found along the way: It is impossible to update windows remotely with powershell. The only API to windows update is apparently a COM interface that refuses to be called remotely. I found a hack on a forum where I have to create a scheduled task that runs as a local admin user and trigger that task remotely. This is farcical. The equivalent of ssh is something called powershell remoting. Of course opening that interface is a significant security risk that need to be monitored. However windows events records all failed authentication attempts on powershell remoting as a local connection and therefore does not expose the IP of the attacker. So much for monitoring. Very few basic functions have been implemented in powershell, half of my powershell script is actually made of traditional batch commands, with all sort of random behaviors (like nslookup makes the script fail), inconsistent API, etc. It feels like using Windows 10 where we are stuck with half of our settings in an old control panel and the other half in a new one, feels sort of half baked. In addition some powershell commands managed to be inferior to their batch equivalent. Setting a registry key is a prime example (and god knows it is a common task), it takes several commands in powershell for something that is done in one command with reg.exe. Of course there is no way to run a ps1 with admin privileges directly from the windows shell [1] etc. [1] winaero has a hack to do that: https://winaero.com/blog/run-as-administrator-context-menu-for-power-shell-ps1-files/ https://winaero.com/blog/run-as-administrator-context-menu-f... But come on Microsoft, don't you use your own product?
  - Arnavion 9y ago
    >Very few basic functions have been implemented in powershell >nslookup [System.Net.Dns]::GetHostAddresses('google.com') | % ToString >In addition some powershell commands managed to be inferior to their batch equivalent. Setting a registry key is a prime example. ... it takes several commands in powershell for something that is done in one command with reg.exe. sp 'HKLM:\path\to\key' name 'value'
    - cm2187 9y ago
      On nslookup, my point is that it shouldn't crash a powershell script. It's a valid windows command. On the registry, your command will fail if HKLM:\path\to\key doesn't exist whereas reg.exe would create the key automatically
jitl 9y ago
You know what also offers cross-platform automation and has packages available on all named operating systems? Bash.
- mrguyorama 9y ago
  The massive paradigm shift that is powershell (ie object based instead of text based) gives it enough space to exist alongside bash. It will not replace bash, and at least on other platforms I highly doubt it's supposed to, as powershell is so heavily Windows focused
  - AnIdiotOnTheNet 9y ago
    Which is very unfortunate in my opinion. Powershell does the UNIX philosophy better than the equivalent traditional toolset by a wide margin. Bourne shell is a clumsy, ugly, footgun-laden automation language and the toolset uses text formatting and parsing in its piping io. The whole thing could really stand to be rethought.
    - mpweiher 9y ago
      > Powershell does the UNIX philosophy better than the equivalent traditional toolset How so? Remember that the "text" convention was not chosen haphazardly, but rather very consciously.
      - wvenable 9y ago
        The convention was chosen back when both CPU and memory were also many orders of magnitude less. Also chosen back when many principles of good software design were still in their infancy. Decisions made 40 years ago were based on entirely different constraints and with a lot less history.
      - bitwize 9y ago
        And it's wrong. Nearly everything taught to you by Unix is wrong. The textual format convention is wrong because text needs to be parsed and unparsed, which is slow and error-prone. Moving objects with clearly defined APIs between programs is more performant and robust. To move objects between machines, use a binary format like Cap'n Proto, which requires no parsing. The only thing text gives you is viewability/editability with vi or nano; with a well-defined, open binary format, tools can be easily written to view and manipulate the raw data streams. Unix's I/O model is broken because it has no intrinsic support for asynchronous I/O. The POSIX aio API sucks, nobody uses it, and it doesn't allow the single syscall check-for-data-and-kickoff-overlapped-I/O-if-not-found that's practically an idiom in Windows (at least not under Linux, where it's implemented in user space via helper processes). The standard multiprocessing primitives in Unix are broken. fork() starts a new process with the same memory image, possessing the same system resources as the old -- convenient in 1979 but highly dangerous in the presence of threads. The correct approach would be to specify a new image to load and run, as in posix_spawn or Windows CreateProcess. In short, fuck Unix and fuck the Unix Philosophy.
unsignedint 9y ago
I've migrated some of bash scripts I use, so the same script can be used for Windows and Linux. Bash ports on Windows can be messy especially if it involves non-Latin codepages, especially when it involves language like Japanese, which frontend is still not migrated fully into UTF-8. (Also WSL handles it more gracefully.) I am program in C# a lot, so extensibility via CmdLet is also interesting. (Although, I haven't explored this much, yet...)
- luch 9y ago
  You should : even if I consider Powershell pretty alien as a language (coming from an old time Windows dev), Cmdlet is vastly superior to other various argument parsing tooling (optparse, argparse, argv, etc.) I've used in the past.
  - ZenoArrow 9y ago
    > "Cmdlet is vastly superior to other various argument parsing tooling (optparse, argparse, argv, etc.) I've used in the past." I can't comment on the other options you listed, but I would agree that PowerShell has good features for parsing arguments (if you use advanced cmdlets, which only require one extra line to enable on basic cmdlet code, for [CmdletBinding()] ). Aside from built-in attributes for enabling common argument checks (like checking for nulls), you can completely customise parameter validation using ValidateScript, which allows you to set up a script that must evaluate as true in order for an argument to be valid. I'd be interested to find out if any Unix command line scripting language offers something similar.
pitaj 9y ago
If only it had `&&`
- seabrookmx 9y ago
  100x yes. The amount of times per day I do something along the lines of git add --all && git commend (commend being an alias for "commit --amend --no-edit") or npm install && npm prune && npm run watch This is the main reason I use git-bash as my primary terminal whenever I'm working on Windows.
  - WorldMaker 9y ago
    Semicolon works, though doesn't have the quit/shortcutting on exit code semantics. There are some community tools to fake it a little better (Get-ExitBoolean). Also, a big GitHub issue tracking it: https://github.com/PowerShell/PowerShell/issues/3241 https://github.com/PowerShell/PowerShell/issues/3241
    - darrenf 9y ago
      > Semicolon works, though doesn't have the quit/shortcutting on exit code semantics. I would say it's a little more than semantics. Consider cd /some/dir/with/a/typo && some_destructive_cmd . vs the semi-colon equivalent.
      - WorldMaker 9y ago
        No, absolutely, there are many cases where semicolon is a bad replacement and a more suitable arrangement found. I'm just speaking to a lot of the "quick one line scripts" that aren't dangerous, such at the parent suggested. Things like `npm install && npm prune` are fine as `npm install; npm prune`. It may "waste" cycles in the rare case of a failed install, but it isn't dangerous. I agree though, a good short-circuiting Boolean operator would be nice.
- tuan 9y ago
  On Windows I use `;` to chain commands.
cutler 9y ago
So long as Microsoft continues to operate its Linux patent racket I won't be letting PowerShell or .Net Core anywhere near my Linux boxen. People, wake-up. It is NOT OK to let Microsoft become another Linux player without holding it to account for its current and past anti-open source practices.
cup-of-tea 9y ago
I'm a bash guy. I'd heard of Powershell and thought it was interesting that Windows finally had something like bash. But back then I didn't use Windows. More recently I had the need to do some scripting for Windows so naturally I looked at Powershell and was excited thinking it would "just like home". It was awful. More like writing Java code than scripting. Except weirdly heterogeneous and ad hoc. I also had to use weird hacks to stop it corrupting every text file with BOM crap. I can't help but thinking the praise Powershell got is just because Windows people have suddenly realised there's more to life than point and click. Well no shit, guys. This is why we've been using Linux this whole time.
antoncohen 9y ago
PowerShell is kind of bizarre. I totally get why is has taken off with Windows sysadmins, compared to the previous built-in alternatives it is amazing. I think a lot of the bizarreness comes from trying to be multiple things, an interactive shell and systems automation language. It is case-insensitive, with seemingly no consensus on what case to use for things. Kinda makes sense for a shell environment with a case-insensitive file system, but very odd when writing automation. It can be written to look like any modern C-like language; set variables, pass variables to functions, etc. But idiomatic PowerShell seems to be (at least in some circles) piping one function to the next in very long chains. Again, that makes sense in a shell, but becomes somewhat unreadable in an application. Most of what I've seen PowerShell used for is automation, from small 1000 line scripts to seriously large applications with libraries and databases. And I can't help but think that Python would have been so much nicer, if only it was built-in to Windows. Python has libraries for working with the Win32 API and COM objects, there is even IronPython which runs on the CRL and can integrate with .NET. I don't think anyone was asking for an interactive shell and a serious programming language to be combined, and it would have been nice if they were separate. Instead they have an awful terminal console, an oddly verbose shell language, and a slow case-insensitive programming language.
- ZenoArrow 9y ago
  > "It is case-insensitive, with seemingly no consensus on what case to use for things." There are naming conventions in PowerShell, but you don't need to know about them when you start out. For example, it's common practice to use camel case for variable names, such as $myVariableName. > "But idiomatic PowerShell seems to be (at least in some circles) piping one function to the next in very long chains." For the code I've seen and written, it's rare to see pipes longer than 4 commands long. If you get any longer than that, it's easy to store the output object in a variable and continue to work with this variable as a shorthand.
  - antoncohen 9y ago
    Regarding case-insensitivity, I'm not referring to user picked names, I'm referring to the whole language. Is it ForEach, Foreach, foreach, or ForEach-Object? Official documentation[1][2][3][4][5] has all four variations. Same for True/False, While, Write-Output, etc. Everything is case-insensitive and the docs can't decide which to use. Again, it kind of makes sense for a shell language when your users are used to case-insensitivity, but I much prefer stricter consistency in programming languages. [1] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_foreach?view=powershell-5.1 https://docs.microsoft.com/en-us/powershell/module/microsoft... [2] https://docs.microsoft.com/en-us/powershell/module/psworkflow/about/about_foreach-parallel?view=powershell-5.1 https://docs.microsoft.com/en-us/powershell/module/psworkflo... [3] https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-powershell-1.0/ee176828(v=technet.10) https://docs.microsoft.com/en-us/previous-versions/windows/i... [4] https://technet.microsoft.com/en-us/library/hh551144.aspx https://technet.microsoft.com/en-us/library/hh551144.aspx [5] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/foreach-object?view=powershell-5.1 https://docs.microsoft.com/en-us/powershell/module/microsoft...
SloopJon 9y ago
Criminy, the Mac tarball expands to over a hundred megabytes, with at least two hundred DLLs and dylibs. If I already have .NET Core installed, is running dotnet pwsh.dll basically the same as running pwsh?
macromaniac 9y ago
If PowerShell is bad because its too much like a programming language thats fine with me. I like being able to hop onto any windows computer and make things happen. I can scrape websites, consume web apis, host webservers, and more all in beautiful one liners. Also text to speech and wscriptshell are fun for messing with your friends computers.
achy2 9y ago
Personal opinion: I tend to find that the times when I end up using advanced Powershell features, I should have been writing code; and times when I don't I could easily have used a batch file. It's too bad that the focus wasn't put on creating an amazing .net interpreter for the commandline.
maxharris 9y ago
From the bottom of the article: Microsoft is a sponsor of The New Stack. Please don't link to articles from The New Stack. Their articles are often nothing more than warmed over press releases...
InclinedPlane 9y ago
Oh goodie, a PowerShell thread on HN. I'm excited to see how many variations of "I hate PowerShell because I've never bothered to spend time learning how to use it, so I don't, and it's also not X, which I use and like" will show up.
rosege 9y ago
As someone thats never been very good at programming in full languages I find that PowerShell is very easy to learn and quite intuitive once you know the basics. I have used it for a huge amount of things that are quite varied. I dont think I've ever had a thought of something I wanted to accomplish and wasnt able to do it (eventually in PowerShell)
telltruth 9y ago
PowerShell is fundamentally flawed system. The object oriented language does not belong to shell. It’s simply too verbose and awkward for repeated fast interactive use. When tons of commands starts with get-*, that’s 4 extra keystrokes before even you begin to specify actual command. I know there are shortcuts but still that’s workaround this bad foundation. A general purpose programming language where you write statement and it stays there and gets executed million times is very different model than shell language where you write statement, throw it away and move on with next. Combining both is creating Frankenstein that’s good at neither. It’s just quite funny that PowerShell syntax doesn’t allow == but does need curlies. Who in the world would have thought of that? Also the view that everything in shell should output structured data is plain wrong. Shell should output human readable formats. always. It’s tool’s job to do proper parsing and deal with related complexity. The convenience should always be afforded to humans, not tools. Even if one changes all built-in commands to comply this, vast majority of programs won’t. So lot of above leads to Frankenstein-ish design that looks like awkward hodge pudge of bandaids. While cross platform is good, MSFT needs to start brand new effort, leave PowerShell behind and take command line to next generation with right first principles.
beagle3 9y ago
For those who don't like PowerShell's syntax and choices, I highly recommend looking at http://xon.sh/tutorial.html http://xon.sh/tutorial.html - it's a marriage of Python and a shell done right, and it's cross platform.

112 points by el_duderino 9y ago

Conceptually, Powershell is really cool. But in practice, I find it both cumbersome and very, very slow. For example: marcel@vger[Downloads]time pwsh -c 'ls' >/dev/null real 0m0.824s user 0m0.636s sys 0m0.213s marcel@vger[Downloads]time sh -c 'ls' >/dev/null real 0m0.011s user 0m0.003s sys 0m0.005s marcel@vger[Downloads] That's around a factor 80. Hmm. OK, startup costs, JITs hard time, yadda yadda. But it's not just that. For example I found a simple dir -r to be more around 50x slower than the equivalent ls -lR And so on.

SwellJoe 9y ago
On top of this, writing PowerShell feels like programming rather than scripting. I know that's sort of ambiguous, but PowerShell is astonishingly verbose compared to bash, or sed/awk, or Perl. PowerShell may be a better programming language than bash, but the times I wrote some, it took me a lot longer (maybe mostly because of my own familiarity with bash) and the resulting scripts were bigger (which I think is unavoidable). I just don't find PowerShell fills a niche I need to fill, even though it seems to be really powerful and designed by smart people. I guess if I worked on Windows it would fill a niche since it has hooks into the system that are harder to reach in other non-MS languages.
- rb808 9y ago
  Sometimes I just want to open a shell and run an exe. With powershell you need to run a command which runs the application. I gave up after that. https://stackoverflow.com/questions/1673967/how-to-run-an-exe-file-in-powershell-with-parameters-with-spaces-and-quotes https://stackoverflow.com/questions/1673967/how-to-run-an-ex...
  - randomString1 9y ago
    What's wrong with .\example.exe? Or .example.exe, .$exampleWithPath for PS1 files? Just examples that I see in the wild
    - rb808 9y ago
      Didn't work for me, I think you have to prepend with a & so & notepad.exe Which isn't complicated I agree but annoyed me.
      - AnIdiotOnTheNet 9y ago
        What version of Powershell are you using? Just typing "notepad" is enough to launch it. The problems with powershell and executables only really come in to play when argument passing, where some escaping is necessary.
        rb808 9y ago
        3, we still have win7 at work.
        joeyaiello 9y ago
        You can download and install PowerShell Core 6 completely side-by-side with Windows PowerShell 3.0. We even have a portable ZIP you can drop down wherever: https://github.com/powershell/powershell/releases https://github.com/powershell/powershell/releases
      - Arnavion 9y ago
        The only reason to use iex is if the thing you're trying to execute is not directly the name of the process. So you need & for `&'notepad'` and `&$string_variable` but not `notepad`
  - gecko 9y ago
    That's not quite correct (and neither is that StackOverflow answer). If you want to execute the EXE stored in a variable or whatnot, then yes, you need `&`, which I think is borrowed from Perl. But otherwise, the rules in PowerShell are the same as a Unix shell: if it's in the PATH, just type the command name (with or without the .exe); otherwise, use the full path.
- wvenable 9y ago
  My biggest complaint with PowerShell is that it's unnecessarily inscrutable -- filled with Bash-like and Perl-like syntax and semantics without the legacy to justify it. I wish writing in PowerShell was as easy as writing C# but instead it's almost as bad as writing Bash scripts. It's not good for programming or scripting. There are so many good ideas in PowerShell but it's wrapped in a weird body.
  - sgtmas2006 9y ago
    I love it for both programming and scripting. It's probably not the best option a lot of the time, but I still find myself going back to write things in PowerShell. I don't find myself running into any of the issues you bring up in my experiences. Everyone has something specific they prefer, though. I find coming back to and reading foreign PowerShell to be quite natural, and rarely taxing if formatted well. I can't pinpoint what I like so much about it either... It just draws me in well. It does devolve in readability when trying to squeeze out every drop of speed, though. IPC is what I find to be the most challenging for me in PoSH, but I'm not sure if that's due to incompetence.
  - darksim905 9y ago
    As a Syasdmin, Powershell is a scripting dream: it has tab completion for the commands and the switches. I don't feel like I have to guess or look at man pages to figure out why there's a -s and an -S. The help pages are usually written for human consumption by comparison. Saying that it is 'unnecessarily inscrutable' is quite hilarious - have you seen some Linux commands & the lack of output they give? Powershell, if anything, ins extremely verbose & is clear in when something goes wrong. At least, it doesn't insult you like Ansible tooling with the ^ YOU MADE A MISTAKE HERE BUT WE CAN'T BE CLEAR WHAT IT IS
    - mattmanser 9y ago
      We have all of that in C# without the rediculously bad syntax. It's such a shame powershell didn't come 2 years later, I feel like they'd have had no choice but to use C# instead of inventing a new language.
- AnIdiotOnTheNet 9y ago
  Powershell has short aliases (and you can define your own too) for the most frequently used commands, and I find the process of reformatting text output between commands to get them to pipe to each other and not choke on formatting differences more cumbersome and time consuming than any extra verbiage added by powershell.
  - contextfree 9y ago
    Most of the aliases use a consistent naming pattern too, which I appreciate.
  - smacktoward 9y ago
    But this can cause other problems. An example would be the way that Powershell for a long time aliased the Invoke-WebRequest cmdlet to both 'curl' and 'wget'. This was supposed to be a convenience feature, but it broke all sorts of scripts that were written to use "real" curl or wget because Invoke-WebRequest didn't accept curl or wget option parameters (oops). They've fixed this in recent versions by shipping actual curl binaries, but it's a useful illustration of how just aliasing popular shell commands to their Powershell alternatives isn't necessarily helpful.
    - contextfree 9y ago
      invoke-webrequest has a "native" short alias too: iwr. I like these native aliases because they use a consistent pattern of abbreviations for verbs and nouns, e.g., the same "i" for invoke is used in icm = invoke-command, iex = invoke-expression, ihy = invoke-history, etc.; then if you look at the nouns in one of those others (since invoke-webrequest is the only "webrequest" cmdlet), they're also consistent, e.g., gcm = get-command, shcm = show-command, trcm = trace-command.
- voidmain0001 9y ago
  I concur. For me personally, PowerShell's dependency on the .Net Framework just makes me write what I need in C# and then deploy to clients using GP. In my environment the client computers don't have a consistent .Net version which follows that they don't have a consistent PS version installed either. For a recent data collection program it was faster and easier to write it in C# and target .Net V2 then to fiddle with PS, and its execution policy https://stackoverflow.com/questions/4037939/powershell-says-execution-of-scripts-is-disabled-on-this-system#4038991 https://stackoverflow.com/questions/4037939/powershell-says-...
  - mistermann 9y ago
    What kind of C# are you writing, is it a compiled exe you're distributing or is there some way to run C# script on windows? I've done almost nothing with PowerShell due to the brutal syntax, would love to use a nice language like C# or Python for the control structure (logic, looping, etc) and then just calling out to PowerShell when needing to execute a function. Seems like that should be a possibility, although passing data through may be problematic.
    - Someone1234 9y ago
      csi.exe runs C# interactively as a script.
    - rusanu 9y ago
      You don't need to 'shell' out to call PoSh. You can host it yourself, see https://msdn.microsoft.com/en-us/library/dn569260(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/dn569260(v=vs.85).a... Passing data is quite easy, both ways, is just C# objects. This can be convenient when faced with one of those 'Powershell only API' features.
    - voidmain0001 9y ago
      It's a compiled binary (PE). I've read through numerous books on PowerShell and I don't see its value in comparison to using any other .Net language. All namespaces in PowerShell are available in C#/VB/blah so why deal with the annoyance of ensuring that the client has not only the required version of .Net Framework/Core installed, but also the PowerShell interpreter version too? Perhaps it's because PowerShell doesn't require a compiled binary so it can be modified and run without an extra step, and it allows for easy add-ins with the cmdlet interface.
- systems 9y ago
  I just to comment on this by saying That whatever space powershell fills on windows its not a niche .. not a niche at all I agree with you, powershell is powerful and I guess benefit from being new .. it has amazing uniformity and amazing discover-ability Anyway, I was saying, powershell fills automation on windows, it is THE automation tool on windows and has been for a while, there is hundreds of commands that you can you to manage and deploy and update almost anything important on windows This is not a niche, not a niche at all .. it is as far from niche as i can think of And now that it is being ported to other systems, it had the potential to be THE automation tool for many organization that have mixed environments So you see, when it was primarily windows, it was not a nice, again because automation on windows is not a niche .. now imagine it beyond even windows Powershell is about automation, not scripting, and not just the command line ... it is really about automation Instead of following steps, you automated with one script ..or possibly a small GUI app
  - SwellJoe 9y ago
    I think you and I merely disagree on the meaning of "niche" in this context, rather than on facts about usage of PowerShell. I was simply saying that PowerShell doesn't serve a unique purpose in my environment that isn't better served by other languages or shells. "Niche" was short-hand for, "This language is particularly well-suited for this task or set of tasks", and I wasn't (intentionally) saying anything about its popularity. All programming languages have a niche where they are strong. It is not a way of saying, "This language is obscure or not used a lot." It's a way of saying, "For the things I do, I can rule it out, because I don't need to do the things this language does better than others." From what I can tell, scripting (or, "automating", if you prefer that term) Windows is PowerShell's niche. I don't need to script Windows, so I don't need PowerShell. In short: Saying PowerShell doesn't fill a niche I need to fill is not an insult to PowerShell or a statement about how popular it is. It's merely saying I don't find it suits my needs in my environment (which contains no Windows servers).
  - mattmanser 9y ago
    As a programmer who knows powershell to an extent, I still make cruddy little console apps rather than piss around with powershell. That's where powershell failed abysmally.
- JeffreySnover 9y ago
  PowerShell was designed to provide a very wide dynamic range of capabilities from interactive actions to simple ad hoc scripts to more formal programming. The goal was to have a single tool that admins and programmers could share to create and manage systems where they could pick how formal they needed to be to solve the problem at hand and can simply modify (vs replace) it as the solution need to be by more people or more production scenarios. Jeffrey Snover [MSFT]
nailer 9y ago
Powershell 6 halved my start times from 1.5s to 720ms. However some things will always be slower, aince powershell does more for you than bash does. Compare productivity from not scraping to consider the tradeoffs.
maxxxxx 9y ago
I have tried PowerShell multiple times and hated it every time. They either should have gone with a language like bash or gone straight to C# as scripting language. Powershell is that weird in between that does nothing well. I know a lot of people love Powershell though.
- taysix 9y ago
  Agreed. I tried automating an installation of some software in powershell. I kept getting different errors on different windows machines depending on what version of Windows they were on and what features they had installed. Ended up rewriting the whole thing in C#. Runs everywhere I need it to and zero issues.
joeyaiello 9y ago
Our filesystem provider could definitely use some performance work, and we're discussing redoing it at some point in the next minor version release or two. Personally, for quick interactive stuff, I just `ls` when I'm sitting on a non-Windows machine. My finger muscle memory just does `ls -al` and `rm -rfv` when I'm sitting on a Linux box. But if I need to do some heavy sorting/filtering, I'd much rather save the minutes wrestling grep/awk/sed/xargs than save the minutes on execution (or the hours on having just done some operation based on some grep/awk/sed/xargs work that I didn't properly test).
cm2187 9y ago
I am more of a windows guy and I have been trying to automate more things with powershell in the last month and I must say that compared to its equivalent in linux it is an absolute dog's breakfast. A few examples of the absurd things I found along the way: It is impossible to update windows remotely with powershell. The only API to windows update is apparently a COM interface that refuses to be called remotely. I found a hack on a forum where I have to create a scheduled task that runs as a local admin user and trigger that task remotely. This is farcical. The equivalent of ssh is something called powershell remoting. Of course opening that interface is a significant security risk that need to be monitored. However windows events records all failed authentication attempts on powershell remoting as a local connection and therefore does not expose the IP of the attacker. So much for monitoring. Very few basic functions have been implemented in powershell, half of my powershell script is actually made of traditional batch commands, with all sort of random behaviors (like nslookup makes the script fail), inconsistent API, etc. It feels like using Windows 10 where we are stuck with half of our settings in an old control panel and the other half in a new one, feels sort of half baked. In addition some powershell commands managed to be inferior to their batch equivalent. Setting a registry key is a prime example (and god knows it is a common task), it takes several commands in powershell for something that is done in one command with reg.exe. Of course there is no way to run a ps1 with admin privileges directly from the windows shell [1] etc. [1] winaero has a hack to do that: https://winaero.com/blog/run-as-administrator-context-menu-for-power-shell-ps1-files/ https://winaero.com/blog/run-as-administrator-context-menu-f... But come on Microsoft, don't you use your own product?
- Arnavion 9y ago
  >Very few basic functions have been implemented in powershell >nslookup [System.Net.Dns]::GetHostAddresses('google.com') | % ToString >In addition some powershell commands managed to be inferior to their batch equivalent. Setting a registry key is a prime example. ... it takes several commands in powershell for something that is done in one command with reg.exe. sp 'HKLM:\path\to\key' name 'value'
  - cm2187 9y ago
    On nslookup, my point is that it shouldn't crash a powershell script. It's a valid windows command. On the registry, your command will fail if HKLM:\path\to\key doesn't exist whereas reg.exe would create the key automatically

jitl 9y ago

You know what also offers cross-platform automation and has packages available on all named operating systems? Bash.

mrguyorama 9y ago
The massive paradigm shift that is powershell (ie object based instead of text based) gives it enough space to exist alongside bash. It will not replace bash, and at least on other platforms I highly doubt it's supposed to, as powershell is so heavily Windows focused
- AnIdiotOnTheNet 9y ago
  Which is very unfortunate in my opinion. Powershell does the UNIX philosophy better than the equivalent traditional toolset by a wide margin. Bourne shell is a clumsy, ugly, footgun-laden automation language and the toolset uses text formatting and parsing in its piping io. The whole thing could really stand to be rethought.
  - mpweiher 9y ago
    > Powershell does the UNIX philosophy better than the equivalent traditional toolset How so? Remember that the "text" convention was not chosen haphazardly, but rather very consciously.
    - wvenable 9y ago
      The convention was chosen back when both CPU and memory were also many orders of magnitude less. Also chosen back when many principles of good software design were still in their infancy. Decisions made 40 years ago were based on entirely different constraints and with a lot less history.
    - bitwize 9y ago
      And it's wrong. Nearly everything taught to you by Unix is wrong. The textual format convention is wrong because text needs to be parsed and unparsed, which is slow and error-prone. Moving objects with clearly defined APIs between programs is more performant and robust. To move objects between machines, use a binary format like Cap'n Proto, which requires no parsing. The only thing text gives you is viewability/editability with vi or nano; with a well-defined, open binary format, tools can be easily written to view and manipulate the raw data streams. Unix's I/O model is broken because it has no intrinsic support for asynchronous I/O. The POSIX aio API sucks, nobody uses it, and it doesn't allow the single syscall check-for-data-and-kickoff-overlapped-I/O-if-not-found that's practically an idiom in Windows (at least not under Linux, where it's implemented in user space via helper processes). The standard multiprocessing primitives in Unix are broken. fork() starts a new process with the same memory image, possessing the same system resources as the old -- convenient in 1979 but highly dangerous in the presence of threads. The correct approach would be to specify a new image to load and run, as in posix_spawn or Windows CreateProcess. In short, fuck Unix and fuck the Unix Philosophy.

unsignedint 9y ago

I've migrated some of bash scripts I use, so the same script can be used for Windows and Linux. Bash ports on Windows can be messy especially if it involves non-Latin codepages, especially when it involves language like Japanese, which frontend is still not migrated fully into UTF-8. (Also WSL handles it more gracefully.) I am program in C# a lot, so extensibility via CmdLet is also interesting. (Although, I haven't explored this much, yet...)

luch 9y ago
You should : even if I consider Powershell pretty alien as a language (coming from an old time Windows dev), Cmdlet is vastly superior to other various argument parsing tooling (optparse, argparse, argv, etc.) I've used in the past.
- ZenoArrow 9y ago
  > "Cmdlet is vastly superior to other various argument parsing tooling (optparse, argparse, argv, etc.) I've used in the past." I can't comment on the other options you listed, but I would agree that PowerShell has good features for parsing arguments (if you use advanced cmdlets, which only require one extra line to enable on basic cmdlet code, for [CmdletBinding()] ). Aside from built-in attributes for enabling common argument checks (like checking for nulls), you can completely customise parameter validation using ValidateScript, which allows you to set up a script that must evaluate as true in order for an argument to be valid. I'd be interested to find out if any Unix command line scripting language offers something similar.

pitaj 9y ago

If only it had `&&`

seabrookmx 9y ago
100x yes. The amount of times per day I do something along the lines of git add --all && git commend (commend being an alias for "commit --amend --no-edit") or npm install && npm prune && npm run watch This is the main reason I use git-bash as my primary terminal whenever I'm working on Windows.
- WorldMaker 9y ago
  Semicolon works, though doesn't have the quit/shortcutting on exit code semantics. There are some community tools to fake it a little better (Get-ExitBoolean). Also, a big GitHub issue tracking it: https://github.com/PowerShell/PowerShell/issues/3241 https://github.com/PowerShell/PowerShell/issues/3241
  - darrenf 9y ago
    > Semicolon works, though doesn't have the quit/shortcutting on exit code semantics. I would say it's a little more than semantics. Consider cd /some/dir/with/a/typo && some_destructive_cmd . vs the semi-colon equivalent.
    - WorldMaker 9y ago
      No, absolutely, there are many cases where semicolon is a bad replacement and a more suitable arrangement found. I'm just speaking to a lot of the "quick one line scripts" that aren't dangerous, such at the parent suggested. Things like `npm install && npm prune` are fine as `npm install; npm prune`. It may "waste" cycles in the rare case of a failed install, but it isn't dangerous. I agree though, a good short-circuiting Boolean operator would be nice.
tuan 9y ago
On Windows I use `;` to chain commands.

cutler 9y ago

So long as Microsoft continues to operate its Linux patent racket I won't be letting PowerShell or .Net Core anywhere near my Linux boxen. People, wake-up. It is NOT OK to let Microsoft become another Linux player without holding it to account for its current and past anti-open source practices.

cup-of-tea 9y ago

I'm a bash guy. I'd heard of Powershell and thought it was interesting that Windows finally had something like bash. But back then I didn't use Windows. More recently I had the need to do some scripting for Windows so naturally I looked at Powershell and was excited thinking it would "just like home". It was awful. More like writing Java code than scripting. Except weirdly heterogeneous and ad hoc. I also had to use weird hacks to stop it corrupting every text file with BOM crap. I can't help but thinking the praise Powershell got is just because Windows people have suddenly realised there's more to life than point and click. Well no shit, guys. This is why we've been using Linux this whole time.

antoncohen 9y ago

PowerShell is kind of bizarre. I totally get why is has taken off with Windows sysadmins, compared to the previous built-in alternatives it is amazing. I think a lot of the bizarreness comes from trying to be multiple things, an interactive shell and systems automation language. It is case-insensitive, with seemingly no consensus on what case to use for things. Kinda makes sense for a shell environment with a case-insensitive file system, but very odd when writing automation. It can be written to look like any modern C-like language; set variables, pass variables to functions, etc. But idiomatic PowerShell seems to be (at least in some circles) piping one function to the next in very long chains. Again, that makes sense in a shell, but becomes somewhat unreadable in an application. Most of what I've seen PowerShell used for is automation, from small 1000 line scripts to seriously large applications with libraries and databases. And I can't help but think that Python would have been so much nicer, if only it was built-in to Windows. Python has libraries for working with the Win32 API and COM objects, there is even IronPython which runs on the CRL and can integrate with .NET. I don't think anyone was asking for an interactive shell and a serious programming language to be combined, and it would have been nice if they were separate. Instead they have an awful terminal console, an oddly verbose shell language, and a slow case-insensitive programming language.

ZenoArrow 9y ago
> "It is case-insensitive, with seemingly no consensus on what case to use for things." There are naming conventions in PowerShell, but you don't need to know about them when you start out. For example, it's common practice to use camel case for variable names, such as $myVariableName. > "But idiomatic PowerShell seems to be (at least in some circles) piping one function to the next in very long chains." For the code I've seen and written, it's rare to see pipes longer than 4 commands long. If you get any longer than that, it's easy to store the output object in a variable and continue to work with this variable as a shorthand.
- antoncohen 9y ago
  Regarding case-insensitivity, I'm not referring to user picked names, I'm referring to the whole language. Is it ForEach, Foreach, foreach, or ForEach-Object? Official documentation[1][2][3][4][5] has all four variations. Same for True/False, While, Write-Output, etc. Everything is case-insensitive and the docs can't decide which to use. Again, it kind of makes sense for a shell language when your users are used to case-insensitivity, but I much prefer stricter consistency in programming languages. [1] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_foreach?view=powershell-5.1 https://docs.microsoft.com/en-us/powershell/module/microsoft... [2] https://docs.microsoft.com/en-us/powershell/module/psworkflow/about/about_foreach-parallel?view=powershell-5.1 https://docs.microsoft.com/en-us/powershell/module/psworkflo... [3] https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-powershell-1.0/ee176828(v=technet.10) https://docs.microsoft.com/en-us/previous-versions/windows/i... [4] https://technet.microsoft.com/en-us/library/hh551144.aspx https://technet.microsoft.com/en-us/library/hh551144.aspx [5] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/foreach-object?view=powershell-5.1 https://docs.microsoft.com/en-us/powershell/module/microsoft...

SloopJon 9y ago

Criminy, the Mac tarball expands to over a hundred megabytes, with at least two hundred DLLs and dylibs. If I already have .NET Core installed, is running dotnet pwsh.dll basically the same as running pwsh?

macromaniac 9y ago

If PowerShell is bad because its too much like a programming language thats fine with me. I like being able to hop onto any windows computer and make things happen. I can scrape websites, consume web apis, host webservers, and more all in beautiful one liners. Also text to speech and wscriptshell are fun for messing with your friends computers.

achy2 9y ago

Personal opinion: I tend to find that the times when I end up using advanced Powershell features, I should have been writing code; and times when I don't I could easily have used a batch file. It's too bad that the focus wasn't put on creating an amazing .net interpreter for the commandline.

maxharris 9y ago

From the bottom of the article: Microsoft is a sponsor of The New Stack. Please don't link to articles from The New Stack. Their articles are often nothing more than warmed over press releases...

InclinedPlane 9y ago

Oh goodie, a PowerShell thread on HN. I'm excited to see how many variations of "I hate PowerShell because I've never bothered to spend time learning how to use it, so I don't, and it's also not X, which I use and like" will show up.

rosege 9y ago

As someone thats never been very good at programming in full languages I find that PowerShell is very easy to learn and quite intuitive once you know the basics. I have used it for a huge amount of things that are quite varied. I dont think I've ever had a thought of something I wanted to accomplish and wasnt able to do it (eventually in PowerShell)

telltruth 9y ago

PowerShell is fundamentally flawed system. The object oriented language does not belong to shell. It’s simply too verbose and awkward for repeated fast interactive use. When tons of commands starts with get-*, that’s 4 extra keystrokes before even you begin to specify actual command. I know there are shortcuts but still that’s workaround this bad foundation. A general purpose programming language where you write statement and it stays there and gets executed million times is very different model than shell language where you write statement, throw it away and move on with next. Combining both is creating Frankenstein that’s good at neither. It’s just quite funny that PowerShell syntax doesn’t allow == but does need curlies. Who in the world would have thought of that? Also the view that everything in shell should output structured data is plain wrong. Shell should output human readable formats. always. It’s tool’s job to do proper parsing and deal with related complexity. The convenience should always be afforded to humans, not tools. Even if one changes all built-in commands to comply this, vast majority of programs won’t. So lot of above leads to Frankenstein-ish design that looks like awkward hodge pudge of bandaids. While cross platform is good, MSFT needs to start brand new effort, leave PowerShell behind and take command line to next generation with right first principles.

beagle3 9y ago

For those who don't like PowerShell's syntax and choices, I highly recommend looking at http://xon.sh/tutorial.html http://xon.sh/tutorial.html - it's a marriage of Python and a shell done right, and it's cross platform.