5 ms·

> Make bash, zsh, ... native for Windows Why? There is PowerShell, able to run on Linux and MacOS. And compared to Bash it is actually readable language.

Falmarri 3y ago
I can't believe there are people that actually like powershell
- raincole 3y ago
  If the alternative is bash then I don't just like powershell, I love it from the bottom of my heart.
- throwaway3563 3y ago
  The main issue with powershell is its name. It would have been better named powerscript. It’s not really a shell but a much more powerful script language along the lines of Perl or PHP.
datagrimx 3y ago
IMO PowerShell is horrible. It is it an object, or not an object. You don't know, unless you know. How about operators? They make ZERO sense (-eq). They went supreme extreme on namespaces. I could write a paper on how bad PowerShell is. You can keep it. I'll stick with zsh or bash.
- metaltyphoon 3y ago
  Ehh debatable. Just two different philosophies. I do think objects > text.
- delta_p_delta_x 3y ago
  > It is it an object, or not an object. It is always an object. Strings, arrays, paths, the registry—everything can be manipulated as an object.
- shiroiushi 3y ago
  Um, to be fair, "-eq" is also an operator in bash.
- Intralexical 3y ago
  > How about operators? They make ZERO sense (-eq). […] I'll stick with zsh or bash. Ah yes. Bash, and its highly intuitive `if /usr/bin/\[ 5 -eq "5" ']'; then :; fi` comparison operators.
  - deleted 3y ago
    [deleted]
- HeavyStorm 3y ago
  Huh... Everything is a object. But that object might be a string. And you don't have to know, you can ask. I get that when everything is text, it becomes simpler to reason about. But you also have to do a lot of maneuvering to get information out of it. PS tries to give you more power. My main gripe with ps is command discoverability: I don't know who thought that the "verb-subject" would be a good idea, because if I type "get-" and tab to auto complete, how the hell will I find the command about networking I want? The learning curve also sucks, but I don't think it's worse than bash. I do remember spending six months with a bash manual tab open in my desktop back when I was starting Linux development. There are also other crazy advantages ps have over bash, like the native ability to understand cmdlets and their parameters, powerful scripting capabilities with decent support for loops, conditionals etc. And I don't event know what to tell you about the operators... They were copied from POSIX, so complaing about then is complaing about bash & co. Finally, PowerShell also let's you access all of the dotnet namespace. This allows you to do a lot of stuff, because you would literally be programing instead of scripting.
  - datagrimx 3y ago
    Shells on Linux/Unix everything can be accessed as a file. Everything. In PowerShell it is a object, or maybe a file, or maybe a handle, or a resource, or a string. A complete catastrophe is Az PowerShell. Why isn't everything a object? The answer is the origins of how Windows handles everything. It diverged every time a new hire took over a subsystem. "Not invented by me" ran strong in those days.
- butlike 3y ago
  PowerShell on *nix is a hellscape realm I wasn't previously aware of.
- PH95VuimJjqBqy 3y ago
  don't even get me started on PS. try this PS script out clear function Get-Strings1 { @('hello') } function Get-Strings2 { @('hello', 'world!') } (Get-Strings1).Length (Get-Strings2).Length OUTPUT: 5 2 You see, PS will strip away the array for 1-element arrays. (Get-Strings1).Length is 5 because you're really calling Length on the string and not the array (the array doesn't exist at that point). As you can see with (Get-Strings2).Length, if there is more than 1 element it will not do this. and you'll watch different features crash into each other in bizarre ways. For example, everything is an object but if that's the case how do you output log statements to the console since it's also a shell? PS is hosted, the default PS host will print out whatever reaches the "top". Think of your PS code as the "first function" with it's own set of returns. The host will print out whatever your code "returns", but this is consistent all the way down the chain. clear function Get-Strings3 { (Do-Stuff) return 'hello' } function Do-Stuff { Write-Output 'haha' } (Get-Strings3).Length OUTPUT: 2 So your returns can be polluted by downstream function calls, including calls into packages that you don't easily have access to the source for. So you'll eventually start writing defensively. (Do-Stuff) | Out-Null # throws away anything coming out of the function call And consider what we've demonstrated here. That PS will happily remove arrays based upon runtime state and happily add them based upon runtime state. If you're confused about why this still happens even though this version uses the return keyword, remember it's PS which means any silly, preconceived notions you have are out the window. returns does two things. 1. Write-Output 2. Ends execution of the function If you remove the return keyword it will have the exact behavior it did previously because it's the last statement in the function. And yes, that's how easy it is to accidentally write something to the output and thus turn your return value into an array. Since I'm on a roll, 1 last example. clear $arr = @($null, 'hello') $isNull = $arr -eq $null $isNull.GetType() OUTPUT: IsPublic IsSerial Name BaseType -------- -------- ---- -------- True True Object[] System.Array How is the equality operator (-eq) returning an array? You see, PS has been lying to you all this time, arrays in PS aren't arrays. They're wrapper objects that pretend to be an array to give all sorts of cool magic. One of those magic things being it's propensity to forward function calls on the array wrapper to the elements themselves. What it's actually doing is calling -eq on each element (think LINQ select) and returning a new array. Which is useful, you can imagine having a list of COM objects with a name property, you can do a select on the name by just doing ".name" on the array wrapper itself. It has its uses. BUT you can't do that for any properties that are on the array (such as Length). Also, PS allows you to attach functions to objects at runtime, if you were truly evil you could attach a myriad of functions to an array object you handed back and laugh as the poor suckers using your code can't understand why calling .Name doesn't forward like it should. ---- I could go on and on and on about PS. I once built a VPS automation solution in PS. My (naive) thinking at the time was that the remoting capabilities for windows was useful so I may as well build it out in powershell. I maintained that solution for 5 years, 4.5 years in and I was _still_ getting surprised by interactions w/i PS. Here's an exercise for the reader. write a function that will successfully test an input parameter against null for everything. There's a solution.
- pjmlp 3y ago
  You never used Perl I see.
yodon 3y ago
Ironically, power shell is the most consistent cross-platform scripting environment today. No more wrangling osx bsd grep commandline flags not working with linux gnu grep, and vice versa. Powershell just works cross platform. And this from a guy whose daily driver is an M3 MacBook.
- HKH2 3y ago
  You don't have to use grep.
SuperNinKenDo 3y ago
I agree. Windows should lean into its original strengths, not become a bad clone of a unix system sitting on top of a non-unix system.
orwin 3y ago
I will explain my point of view, please comment on if you think my view is fair, or if I'm wrong. My issue with powershell is that it isn't really a shell language, or rather, not a tty language. I do think it's way better than bash, but I do not want to use it like bash, I want to use it like AWK, but for my system. I want it to use it only in scripts, or with an exec in a command line at worst. I think bash have better built-in for ttys, and is faster/more reactive (that might be my windows config but I don't think so). I want to navigate with bash, and script with powershell (which I do to be completely honest, but I'd like to do that in a windows terminal and not wsl).

Falmarri 3y ago

I can't believe there are people that actually like powershell

raincole 3y ago
If the alternative is bash then I don't just like powershell, I love it from the bottom of my heart.
throwaway3563 3y ago
The main issue with powershell is its name. It would have been better named powerscript. It’s not really a shell but a much more powerful script language along the lines of Perl or PHP.

datagrimx 3y ago

IMO PowerShell is horrible. It is it an object, or not an object. You don't know, unless you know. How about operators? They make ZERO sense (-eq). They went supreme extreme on namespaces. I could write a paper on how bad PowerShell is. You can keep it. I'll stick with zsh or bash.

metaltyphoon 3y ago
Ehh debatable. Just two different philosophies. I do think objects > text.
delta_p_delta_x 3y ago
> It is it an object, or not an object. It is always an object. Strings, arrays, paths, the registry—everything can be manipulated as an object.
shiroiushi 3y ago
Um, to be fair, "-eq" is also an operator in bash.
Intralexical 3y ago
> How about operators? They make ZERO sense (-eq). […] I'll stick with zsh or bash. Ah yes. Bash, and its highly intuitive `if /usr/bin/\[ 5 -eq "5" ']'; then :; fi` comparison operators.
- deleted 3y ago
  [deleted]
HeavyStorm 3y ago
Huh... Everything is a object. But that object might be a string. And you don't have to know, you can ask. I get that when everything is text, it becomes simpler to reason about. But you also have to do a lot of maneuvering to get information out of it. PS tries to give you more power. My main gripe with ps is command discoverability: I don't know who thought that the "verb-subject" would be a good idea, because if I type "get-" and tab to auto complete, how the hell will I find the command about networking I want? The learning curve also sucks, but I don't think it's worse than bash. I do remember spending six months with a bash manual tab open in my desktop back when I was starting Linux development. There are also other crazy advantages ps have over bash, like the native ability to understand cmdlets and their parameters, powerful scripting capabilities with decent support for loops, conditionals etc. And I don't event know what to tell you about the operators... They were copied from POSIX, so complaing about then is complaing about bash & co. Finally, PowerShell also let's you access all of the dotnet namespace. This allows you to do a lot of stuff, because you would literally be programing instead of scripting.
- datagrimx 3y ago
  Shells on Linux/Unix everything can be accessed as a file. Everything. In PowerShell it is a object, or maybe a file, or maybe a handle, or a resource, or a string. A complete catastrophe is Az PowerShell. Why isn't everything a object? The answer is the origins of how Windows handles everything. It diverged every time a new hire took over a subsystem. "Not invented by me" ran strong in those days.
butlike 3y ago
PowerShell on *nix is a hellscape realm I wasn't previously aware of.
PH95VuimJjqBqy 3y ago
don't even get me started on PS. try this PS script out clear function Get-Strings1 { @('hello') } function Get-Strings2 { @('hello', 'world!') } (Get-Strings1).Length (Get-Strings2).Length OUTPUT: 5 2 You see, PS will strip away the array for 1-element arrays. (Get-Strings1).Length is 5 because you're really calling Length on the string and not the array (the array doesn't exist at that point). As you can see with (Get-Strings2).Length, if there is more than 1 element it will not do this. and you'll watch different features crash into each other in bizarre ways. For example, everything is an object but if that's the case how do you output log statements to the console since it's also a shell? PS is hosted, the default PS host will print out whatever reaches the "top". Think of your PS code as the "first function" with it's own set of returns. The host will print out whatever your code "returns", but this is consistent all the way down the chain. clear function Get-Strings3 { (Do-Stuff) return 'hello' } function Do-Stuff { Write-Output 'haha' } (Get-Strings3).Length OUTPUT: 2 So your returns can be polluted by downstream function calls, including calls into packages that you don't easily have access to the source for. So you'll eventually start writing defensively. (Do-Stuff) | Out-Null # throws away anything coming out of the function call And consider what we've demonstrated here. That PS will happily remove arrays based upon runtime state and happily add them based upon runtime state. If you're confused about why this still happens even though this version uses the return keyword, remember it's PS which means any silly, preconceived notions you have are out the window. returns does two things. 1. Write-Output 2. Ends execution of the function If you remove the return keyword it will have the exact behavior it did previously because it's the last statement in the function. And yes, that's how easy it is to accidentally write something to the output and thus turn your return value into an array. Since I'm on a roll, 1 last example. clear $arr = @($null, 'hello') $isNull = $arr -eq $null $isNull.GetType() OUTPUT: IsPublic IsSerial Name BaseType -------- -------- ---- -------- True True Object[] System.Array How is the equality operator (-eq) returning an array? You see, PS has been lying to you all this time, arrays in PS aren't arrays. They're wrapper objects that pretend to be an array to give all sorts of cool magic. One of those magic things being it's propensity to forward function calls on the array wrapper to the elements themselves. What it's actually doing is calling -eq on each element (think LINQ select) and returning a new array. Which is useful, you can imagine having a list of COM objects with a name property, you can do a select on the name by just doing ".name" on the array wrapper itself. It has its uses. BUT you can't do that for any properties that are on the array (such as Length). Also, PS allows you to attach functions to objects at runtime, if you were truly evil you could attach a myriad of functions to an array object you handed back and laugh as the poor suckers using your code can't understand why calling .Name doesn't forward like it should. ---- I could go on and on and on about PS. I once built a VPS automation solution in PS. My (naive) thinking at the time was that the remoting capabilities for windows was useful so I may as well build it out in powershell. I maintained that solution for 5 years, 4.5 years in and I was _still_ getting surprised by interactions w/i PS. Here's an exercise for the reader. write a function that will successfully test an input parameter against null for everything. There's a solution.
pjmlp 3y ago
You never used Perl I see.

yodon 3y ago

Ironically, power shell is the most consistent cross-platform scripting environment today. No more wrangling osx bsd grep commandline flags not working with linux gnu grep, and vice versa. Powershell just works cross platform. And this from a guy whose daily driver is an M3 MacBook.

HKH2 3y ago
You don't have to use grep.

SuperNinKenDo 3y ago

I agree. Windows should lean into its original strengths, not become a bad clone of a unix system sitting on top of a non-unix system.

orwin 3y ago

I will explain my point of view, please comment on if you think my view is fair, or if I'm wrong. My issue with powershell is that it isn't really a shell language, or rather, not a tty language. I do think it's way better than bash, but I do not want to use it like bash, I want to use it like AWK, but for my system. I want it to use it only in scripts, or with an exec in a command line at worst. I think bash have better built-in for ttys, and is faster/more reactive (that might be my windows config but I don't think so). I want to navigate with bash, and script with powershell (which I do to be completely honest, but I'd like to do that in a windows terminal and not wsl).