5 ms·

I'll share a bit of personal experience for those who hate PowerShell to maybe make them look at it from a new point of view. As a devoted Unix fanatic, I used

I'll share a bit of personal experience for those who hate PowerShell to maybe make them look at it from a new point of view. As a devoted Unix fanatic, I used to hate PowerShell, because I initially came in with the expectation that it's going to be “just another POSIX-like shell”. After all, it's right in the name! And it uses dollar signs! So every little thing that differed from my unixey expectations made me angry. (Them using awful aliases like wget and curl didn't help. Seriously, what were they thinking?) But once I've realized that PowerShell is much closer to AWK and Perl, I kind of started to almost enjoy it. Don't get me wrong, it's not my favourite language or anything. But these days I think that it is a formidable scripting language with most of the stuff you'd normally need in place, at least in the recent versions. One thing that I still dislike is the absence of something like the Unix manual pages. For some reason, help pages require additional installation, and the learn.microsoft.com search is so awful that it's often quicker to use DDG with "site:learn.microsoft.com".

mananaysiempre 3y ago
> I've realized that PowerShell is much closer to AWK and Perl [than to POSIX shell] For me, what distinguishes[1,2] the former category from the latter one is that the latter one is quick and comfortable to use interactively, as a shell for the OS, to iterate at the command line and not in the editor, while the former one... isn’t. The cost is that a couple hundred lines of AWK are usually fairly OK, while the same amount of shell visibly strains the language. Are we still in the world where the interactive text-based environment (not programming environment) with the best available ergonomics is based on a general framework set in 1979? I’m aware Lisp machines existed and did things differently, but the best you can get in that respect now is Emacs and it still cannot reach that seamless ad-hoc composability of Bourne shell. [1] http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html [2] https://scsh.net/docu/html/man-Z-H-1.html#node_toc_node_sec_1.4 https://scsh.net/docu/html/man-Z-H-1.html#node_toc_node_sec_...
- throw_a_grenade 3y ago
  > Are we still in the world where the interactive text-based environment (not programming environment) with the best available ergonomics is based on a general framework set in 1979? Yes, because it's not broken (certainly not for interactive use), so it's not in a need for fixing. People who don't understand it are doomed to reinvent it poorly (vide curl/wget aliases in powershell).
  - jodrellblank 3y ago
    People who don't understand PowerShell are doomed to bikeshed two aliases from an entire shell, programming language, and ecosystem of OS integration and tooling. > "Yes, because it's not broken (certainly not for interactive use)" It's not /broken/, it's dated, limited in the way "turn everything to CSV or JSON and turn it back" is becoming common as a clunky workaround, limited and weak as a programming/scripting environment with hard boundaries making it difficult to extend or build on without having to switch to a completely different thing like Python/Perl, inconsistent and arbitrary with all commands doing their own thing for argument parsing and input/output formatting and style of human interface, and all being isolated silos, it's easy to do badly and difficult to do well. PowerShell parses command parameters at the shell level. So they're all consistently handled, there isn't the same "this command has weird argument parsing". That means the engine can look into the cmdlets and interrogate them in standard ways and present hints about usage from their help comments. PowerShell is a scripting language and lets you reach for the .NET framework when its builtin commands aren't enough, and then lets you build commands in C# still for more flexibility or performance but still using the PowerShell engine for parameter processing and from there lets you build modules for ease of deployment to different machines. PowerShell engine has scriptable tokeniser, AST, meaning your code can process PowerShell code and editors can lean on the engine for syntax highlighting and autocompletion instead of using regexes from before LSPs.
    - actionfromafar 3y ago
      Powershell is very cool and the object model and .NET integration is awesome. I just wish that Microsoft adapted Lua or Javascript or massaged Python or whatever something instead of inventing a language with yet another weird syntax.
jodrellblank 3y ago
> "Them using awful aliases like wget and curl didn't help. Seriously, what were they thinking? Seriously they were thinking "if people open our new shell, type a command they expect to work and get an error, they will quit it and never come back. Let's make some aliases for common commands to give people a helping hand so that `cd` and `dir` and `type` and `move` and so on from command prompt, and `echo` and `ls` and `cat` and `md` and `ps` and `mv` and so on from Unix shell, all do something useful. If people have to start right in with PowerShell specific `gci` (get-childitem) and `sl` (set-location) and `mi` (move-item) that will be too unfriendly and too steep learning curve. It was a great idea; if you're a Linux user you're well aware that the same command can behave differently on different systems (see: grep, egrep, fgrep, POSIX standards vs GNU utilities) and both aware and comfortable with customising your environment with startup scripts (removing aliases if you don't want them). On the other hand if they didn't do that, they were going to get grief from the Windows side (breaking backwards compatibility) and from the Linux side ('all shells must be POSIX'). Damned if they do, damned if they don't. At the time (~2006) PowerShell was Windows only and CURL was not a common Windows tool.
- YeGoblynQueenne 3y ago
  Besides, it's just faster to write "ls" than "Get-ChildItem". Linux command names come from a time when pressing keys on a keyboard was very expensive [1], so they're very economical. Nowadays we can type keyboard keys as long and as fast as we want and shell command names just get longer and longer. ________________ [1] In the 1960's it cost 10 XP to press one key. 15 for the Return key.
  - kevviiinn 3y ago
    What is XP in this context?
    - YeGoblynQueenne 3y ago
      Windows Experience Points? Sorry, it's all tongue-in-cheek.
  - 3y ago
WorldMaker 3y ago
> One thing that I still dislike is the absence of something like the Unix manual pages. For some reason, help pages require additional installation, and the learn.microsoft.com search is so awful that it's often quicker to use DDG with "site:learn.microsoft.com". I haven't found a case where `Get-Help` hasn't met most of my need for something like Unix `man`. `Get-Help` is even by default "helpfully" aliased to `man` in PowerShell. It is weird that sometimes you need to `Update-Help` somewhat frequently, especially if you install a lot of modules regularly, but some tools have gotten better at calling it automatically after module installs and I believe the PowerShell 7+ installers have gotten better than before about making sure the built-in modules are all up-to-date at install time and not just uninstalled/missing. It's also not that weird when you look at how complicated man page installation is in most distributions of Unix (even if it feels magic when it works). Also, the `-Online` argument to `Get-Help` sends your default browser to the relevant learn.microsoft.com documentation page for most commands. That's a very handy shortcut to searching in my experience.

mananaysiempre 3y ago

> I've realized that PowerShell is much closer to AWK and Perl [than to POSIX shell] For me, what distinguishes[1,2] the former category from the latter one is that the latter one is quick and comfortable to use interactively, as a shell for the OS, to iterate at the command line and not in the editor, while the former one... isn’t. The cost is that a couple hundred lines of AWK are usually fairly OK, while the same amount of shell visibly strains the language. Are we still in the world where the interactive text-based environment (not programming environment) with the best available ergonomics is based on a general framework set in 1979? I’m aware Lisp machines existed and did things differently, but the best you can get in that respect now is Emacs and it still cannot reach that seamless ad-hoc composability of Bourne shell. [1] http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html [2] https://scsh.net/docu/html/man-Z-H-1.html#node_toc_node_sec_1.4 https://scsh.net/docu/html/man-Z-H-1.html#node_toc_node_sec_...

throw_a_grenade 3y ago
> Are we still in the world where the interactive text-based environment (not programming environment) with the best available ergonomics is based on a general framework set in 1979? Yes, because it's not broken (certainly not for interactive use), so it's not in a need for fixing. People who don't understand it are doomed to reinvent it poorly (vide curl/wget aliases in powershell).
- jodrellblank 3y ago
  People who don't understand PowerShell are doomed to bikeshed two aliases from an entire shell, programming language, and ecosystem of OS integration and tooling. > "Yes, because it's not broken (certainly not for interactive use)" It's not /broken/, it's dated, limited in the way "turn everything to CSV or JSON and turn it back" is becoming common as a clunky workaround, limited and weak as a programming/scripting environment with hard boundaries making it difficult to extend or build on without having to switch to a completely different thing like Python/Perl, inconsistent and arbitrary with all commands doing their own thing for argument parsing and input/output formatting and style of human interface, and all being isolated silos, it's easy to do badly and difficult to do well. PowerShell parses command parameters at the shell level. So they're all consistently handled, there isn't the same "this command has weird argument parsing". That means the engine can look into the cmdlets and interrogate them in standard ways and present hints about usage from their help comments. PowerShell is a scripting language and lets you reach for the .NET framework when its builtin commands aren't enough, and then lets you build commands in C# still for more flexibility or performance but still using the PowerShell engine for parameter processing and from there lets you build modules for ease of deployment to different machines. PowerShell engine has scriptable tokeniser, AST, meaning your code can process PowerShell code and editors can lean on the engine for syntax highlighting and autocompletion instead of using regexes from before LSPs.
  - actionfromafar 3y ago
    Powershell is very cool and the object model and .NET integration is awesome. I just wish that Microsoft adapted Lua or Javascript or massaged Python or whatever something instead of inventing a language with yet another weird syntax.

jodrellblank 3y ago

> "Them using awful aliases like wget and curl didn't help. Seriously, what were they thinking? Seriously they were thinking "if people open our new shell, type a command they expect to work and get an error, they will quit it and never come back. Let's make some aliases for common commands to give people a helping hand so that `cd` and `dir` and `type` and `move` and so on from command prompt, and `echo` and `ls` and `cat` and `md` and `ps` and `mv` and so on from Unix shell, all do something useful. If people have to start right in with PowerShell specific `gci` (get-childitem) and `sl` (set-location) and `mi` (move-item) that will be too unfriendly and too steep learning curve. It was a great idea; if you're a Linux user you're well aware that the same command can behave differently on different systems (see: grep, egrep, fgrep, POSIX standards vs GNU utilities) and both aware and comfortable with customising your environment with startup scripts (removing aliases if you don't want them). On the other hand if they didn't do that, they were going to get grief from the Windows side (breaking backwards compatibility) and from the Linux side ('all shells must be POSIX'). Damned if they do, damned if they don't. At the time (~2006) PowerShell was Windows only and CURL was not a common Windows tool.

YeGoblynQueenne 3y ago
Besides, it's just faster to write "ls" than "Get-ChildItem". Linux command names come from a time when pressing keys on a keyboard was very expensive [1], so they're very economical. Nowadays we can type keyboard keys as long and as fast as we want and shell command names just get longer and longer. ________________ [1] In the 1960's it cost 10 XP to press one key. 15 for the Return key.
- kevviiinn 3y ago
  What is XP in this context?
  - YeGoblynQueenne 3y ago
    Windows Experience Points? Sorry, it's all tongue-in-cheek.
- 3y ago

WorldMaker 3y ago

> One thing that I still dislike is the absence of something like the Unix manual pages. For some reason, help pages require additional installation, and the learn.microsoft.com search is so awful that it's often quicker to use DDG with "site:learn.microsoft.com". I haven't found a case where `Get-Help` hasn't met most of my need for something like Unix `man`. `Get-Help` is even by default "helpfully" aliased to `man` in PowerShell. It is weird that sometimes you need to `Update-Help` somewhat frequently, especially if you install a lot of modules regularly, but some tools have gotten better at calling it automatically after module installs and I believe the PowerShell 7+ installers have gotten better than before about making sure the built-in modules are all up-to-date at install time and not just uninstalled/missing. It's also not that weird when you look at how complicated man page installation is in most distributions of Unix (even if it feels magic when it works). Also, the `-Online` argument to `Get-Help` sends your default browser to the relevant learn.microsoft.com documentation page for most commands. That's a very handy shortcut to searching in my experience.