26 ms·

I find it quiet funny there are a bunch of unix sysadmins in here talking about how PS isn't great, but admit to only touching it "sometimes" for some minor use

I find it quiet funny there are a bunch of unix sysadmins in here talking about how PS isn't great, but admit to only touching it "sometimes" for some minor use case. Well, no shit. I now do cloud/unix/windows dev and formerly used to admin both types and use both bash and PS and have to say I like PS better, only because the community around it is less toxic and does not gatekeep. From actual REPL language POV though, PS serves its purpose quiet well and I look forward to where it takes us in the future.

chasil 5y ago
Get it into Busybox, and we will talk. Until then, the footprint is too big, and the installed base is too small. Microsoft itself is responsible for the POSIX shell - it was required to compile into a 64k text segment on Microsoft Xenix. Without Bill's beloved Xenix, ksh88 would have been the POSIX standard. It's all Microsoft's fault.
bastardoperator 5y ago
In my limited experience it always looks like a lot more typing to get similar bash like results so for that reason alone I just avoid it.
- Someone1234 5y ago
  People that base what tooling they use around how many characters they have to type instead of how productive it makes them seems common but problematic. I simply cannot relate to this prioritization.
  - bastardoperator 5y ago
    If it take me twice as long to get to the same solution, I'm ultimately less productive. I tend to abide by the "less is more" philosophy.
    - Someone1234 5y ago
      > If it take me twice as long to get to the same solution, I'm ultimately less productive. Exactly, that's why having to guess command/args and google the man-page is way less productive by a lot. For minimal productivity gains in the time it takes you to type a few characters you've wasted minutes.
      - bastardoperator 5y ago
        Google the man page? I hope you're not serious.
- brazzledazzle 5y ago
  It shines when you take advantage of it's object model. You are passing around and operating on objects with types, properties, etc. vs. what's effectively glorified string manipulation with bash. That comes with tradeoffs though like the one you mentioned. Memory usage when operating on large datasets is another. Another big benefit mentioned elsewhere is that you can bring in C# directly into the shell.
- WorldMaker 5y ago
  In a reasonably modern terminal, tab completion makes it a lot less typing than it appears. The other thing is that idiomatic PowerShell takes a "Python perspective" that scripts are often read way more often than they are written and the best, idiomatic examples often use the most verbose forms of names to make things clearer to read. PowerShell has a very rich aliases system with many, much shorter names for almost everything (and the ability to define your own to your heart's desire; and the ability to list which aliases are active on a current system), and you absolutely can code golf PS1 commands down into very bash-like lines. Most PowerShell veterans tend to write extremely terse stuff at the REPL even when in scripts and online documentation they try to stick to the idiomatic verbosity for others that need to read the scripts and understand what they do (even sometimes themselves months or years later).
  - majkinetor 5y ago
    Exactly. Not only use of cmdlet aliases make shorter syntax but also: - Shortening parameter names to unique prefix - Use of parameter aliases - Use of automatic pipeline property binder In my experience achieving the same or shorter one-liners for the same task as with bash is typical.
    - bastardoperator 5y ago
      Seems like you're speaking a different language as someone that's been working in a terminal for almost 20 years. Again, my exposure is to pwsh is very limited, any good examples or comparisons you might suggest?
      - watersb 5y ago
        I'm not quite sure if I'm addressing your question; I am not as familiar with PowerShell as I am with various unix-like command shells. But an example that springs to mind for me is "Get-ChildItem". Two default aliases for this PowerShell command are `ls` and `dir`. PowerShell seems to build upon data structures, can pass these around much in the same way that is done in the REPL of an interpreter. Unix shells lean on the file system for that: if you want to "really" pass around data structures, you pass the name of associated file handles, as defined in the namespace of the virtual file system (VFS). It turn out that the unix way is usually quite sufficient for interactive sessions. Remarkably so. But I can write PowerShell functions that do type checking. I can sign PowerShell files with a certificate that implements a security policy... Stuff like that can be done by a Unix shell and VFS in 2021, but the complexity trade-offs start to favor programming environments with a typed call stack.
yjftsjthsd-h 5y ago
> I find it quiet funny there are a bunch of unix sysadmins in here talking about how PS isn't great, but admit to only touching it "sometimes" for some minor use case. Well, no shit. So, you want them to use it a lot when they don't like it?
- blibble 5y ago
  that's basically Microsoft's business model
908B64B197 5y ago
Powershell is a weird beast for sure. Takes care of the parsing and makes pipelines less brittle for sure (just look at things like NO_COLOR [0] that are basically "please adopt this so we can stop having to add endless edge cases to strip ansi color codes") because it keeps data flowing between programs into a machine-friendly format. It's only when it reaches a human that it is formatted for a human to see. Then when you peel off the surface you realize you can invoke C# directly from the shell. That's right, either you can import any C# .dll out there and call it from the shell or flat out write C# in your script and have Powershell execute it at runtime [2]. You can add syntaxic sugar to make your dll easier to work with but any C# dll can be called from powershell. As a side effect, this means that if you have a front-end/back-end app with the back-end written in C#, you also have a (bad) scripting interface basically for free. [0] https://no-color.org/ https://no-color.org/ [2] https://tekcookie.com/use-c-in-powershell/ https://tekcookie.com/use-c-in-powershell/

chasil 5y ago

Get it into Busybox, and we will talk. Until then, the footprint is too big, and the installed base is too small. Microsoft itself is responsible for the POSIX shell - it was required to compile into a 64k text segment on Microsoft Xenix. Without Bill's beloved Xenix, ksh88 would have been the POSIX standard. It's all Microsoft's fault.

bastardoperator 5y ago

In my limited experience it always looks like a lot more typing to get similar bash like results so for that reason alone I just avoid it.

Someone1234 5y ago
People that base what tooling they use around how many characters they have to type instead of how productive it makes them seems common but problematic. I simply cannot relate to this prioritization.
- bastardoperator 5y ago
  If it take me twice as long to get to the same solution, I'm ultimately less productive. I tend to abide by the "less is more" philosophy.
  - Someone1234 5y ago
    > If it take me twice as long to get to the same solution, I'm ultimately less productive. Exactly, that's why having to guess command/args and google the man-page is way less productive by a lot. For minimal productivity gains in the time it takes you to type a few characters you've wasted minutes.
    - bastardoperator 5y ago
      Google the man page? I hope you're not serious.
brazzledazzle 5y ago
It shines when you take advantage of it's object model. You are passing around and operating on objects with types, properties, etc. vs. what's effectively glorified string manipulation with bash. That comes with tradeoffs though like the one you mentioned. Memory usage when operating on large datasets is another. Another big benefit mentioned elsewhere is that you can bring in C# directly into the shell.
WorldMaker 5y ago
In a reasonably modern terminal, tab completion makes it a lot less typing than it appears. The other thing is that idiomatic PowerShell takes a "Python perspective" that scripts are often read way more often than they are written and the best, idiomatic examples often use the most verbose forms of names to make things clearer to read. PowerShell has a very rich aliases system with many, much shorter names for almost everything (and the ability to define your own to your heart's desire; and the ability to list which aliases are active on a current system), and you absolutely can code golf PS1 commands down into very bash-like lines. Most PowerShell veterans tend to write extremely terse stuff at the REPL even when in scripts and online documentation they try to stick to the idiomatic verbosity for others that need to read the scripts and understand what they do (even sometimes themselves months or years later).
- majkinetor 5y ago
  Exactly. Not only use of cmdlet aliases make shorter syntax but also: - Shortening parameter names to unique prefix - Use of parameter aliases - Use of automatic pipeline property binder In my experience achieving the same or shorter one-liners for the same task as with bash is typical.
  - bastardoperator 5y ago
    Seems like you're speaking a different language as someone that's been working in a terminal for almost 20 years. Again, my exposure is to pwsh is very limited, any good examples or comparisons you might suggest?
    - watersb 5y ago
      I'm not quite sure if I'm addressing your question; I am not as familiar with PowerShell as I am with various unix-like command shells. But an example that springs to mind for me is "Get-ChildItem". Two default aliases for this PowerShell command are `ls` and `dir`. PowerShell seems to build upon data structures, can pass these around much in the same way that is done in the REPL of an interpreter. Unix shells lean on the file system for that: if you want to "really" pass around data structures, you pass the name of associated file handles, as defined in the namespace of the virtual file system (VFS). It turn out that the unix way is usually quite sufficient for interactive sessions. Remarkably so. But I can write PowerShell functions that do type checking. I can sign PowerShell files with a certificate that implements a security policy... Stuff like that can be done by a Unix shell and VFS in 2021, but the complexity trade-offs start to favor programming environments with a typed call stack.

yjftsjthsd-h 5y ago

> I find it quiet funny there are a bunch of unix sysadmins in here talking about how PS isn't great, but admit to only touching it "sometimes" for some minor use case. Well, no shit. So, you want them to use it a lot when they don't like it?

blibble 5y ago
that's basically Microsoft's business model

908B64B197 5y ago

Powershell is a weird beast for sure. Takes care of the parsing and makes pipelines less brittle for sure (just look at things like NO_COLOR [0] that are basically "please adopt this so we can stop having to add endless edge cases to strip ansi color codes") because it keeps data flowing between programs into a machine-friendly format. It's only when it reaches a human that it is formatted for a human to see. Then when you peel off the surface you realize you can invoke C# directly from the shell. That's right, either you can import any C# .dll out there and call it from the shell or flat out write C# in your script and have Powershell execute it at runtime [2]. You can add syntaxic sugar to make your dll easier to work with but any C# dll can be called from powershell. As a side effect, this means that if you have a front-end/back-end app with the back-end written in C#, you also have a (bad) scripting interface basically for free. [0] https://no-color.org/ https://no-color.org/ [2] https://tekcookie.com/use-c-in-powershell/ https://tekcookie.com/use-c-in-powershell/