8 ms·

On top of this, writing PowerShell feels like programming rather than scripting. I know that's sort of ambiguous, but PowerShell is astonishingly verbose compar

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.
  - Arnavion 9y ago
    >That's not quite correct (and neither is that StackOverflow answer). The SO answer isn't wrong. The EXE there has a space in the path. The answer uses a string literal for it and thus needs &. It could of course escape the spaces with ` instead; then it wouldn't need a string literal and thus not need &.
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]

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.
- Arnavion 9y ago
  >That's not quite correct (and neither is that StackOverflow answer). The SO answer isn't wrong. The EXE there has a space in the path. The answer uses a string literal for it and thus needs &. It could of course escape the spaces with ` instead; then it wouldn't need a string literal and thus not need &.

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]