5 ms·

> the experience of using PS was superior to that of bash As a Linux dweller, I'm genuinely curious about this one. I've found PS inferior in just about any us

by chmln 10y ago

> the experience of using PS was superior to that of bash As a Linux dweller, I'm genuinely curious about this one. I've found PS inferior in just about any use case.

thomas11 10y ago
I've used both extensively and I think they are fairly different, with different strengths and weaknesses. Bash is more pragmatic and more concise on the command line. PS is more uniform in its design and nicer for scripting IMO. It allows passing objects through pipes, has built-in JSON reading and writing, built-in parameter handling with defaults, mandatory and optional params, switches etc., and such niceties.
- majkinetor 10y ago
  Bash is not more concise, its other way around, of course, if you use default aliases. The reasons is logical - you almost never use text parsing in Posh while you almost never have anything without it in bash.
  - AsyncAwait 10y ago
    I find Powershell non intuitive to learn honestly, Bash just clicks with me way more for some reason.
majkinetor 10y ago
I used majority of mainstream shells and Posh is a scpace ship compared to any other in existence. I wont reiterate again and again why, there are planty of places eihter on HN, reddit or SO why is it so. I guess you will have to give it a serious try.
jciochon 10y ago
I go back and forth between windows/unix for my day job and I also would be curious on any actual bullet points. I find that even in a situation where PS could potentially prove more useful or has an extra feature, what you end up with is a new set of chrome tabs open just to try and figure out how to do the thing. I suppose this might(?) be mitigated if you're embedded in the .NET world, but I just can't seem to get the memory down for the silly cmdlet naming and since they also have the admittedly interesting object-piping thing going on, you're always battling two pain points at a time instead of just one (e.g. syntax/naming in bash)
- WorldMaker 10y ago
  One of the best bits of PS1 advice I've seen was to get used to the Verb-Noun naming pattern [1] and in particular, the discoverability of the very standardized set of verbs [2]. Once you can guess the verb you want, then it can often be a simple matter of finding the right noun, and often nouns will be useful in sets similar to verbs. Get-Verb, Get-Command, and Get-Help are all quite useful for looking for a command. For dealing with the object pipeline I tend to find ConvertTo-Json very handy because as a developer I'm already quite used to reading objects in JSON already. (ConvertFrom-Json can similarly be used to bootstrap a PS1 pipeline with test data or remote data.) [1] https://blogs.technet.microsoft.com/heyscriptingguy/2012/05/14/discover-the-easy-way-to-begin-learning-windows-powershell/ https://blogs.technet.microsoft.com/heyscriptingguy/2012/05/... [2] https://msdn.microsoft.com/en-us/library/ms714428(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/ms714428(v=vs.85).a...
yokohummer7 10y ago
I had been a full-time Linux (desktop) user for more than 10 years, and only recently made a transition to Windows. As I'm nowhere proficient at using PowerShell I might be overrating it a bit, as the grass is always greener on the other side. Anyways, what I found to be satisfying while using PS were: 1. The input/output is done using objects. I know that "inter-process communication should be done with text" is the UNIX philosophy, and I appreciated that when using Linux, but after using PS I started to have mixed feelings about that. When using bash/zsh, I typically used awk to extract the data I wanted from the text emitted by an external process. Doing so isn't hard, mostly as simple as using `awk {print $3}` or something like that, but it is still a bit annoyance and more importantly, vulnerable to the changes in the output format. PS cmdlets communicate with themselves using objects, so it is very easy to extract some columns out of the command results. For example, when I query about a process in PS: PS> Get-Process -Name chrome Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName ------- ------ ----- ----- ------ -- -- ----------- 362 80 169636 109896 36,411.16 484 1 chrome 497 113 274988 132544 5,161.00 656 1 chrome 404 84 87444 55356 303.56 764 1 chrome If I want to extract CPU time and process ID: PS> Get-Process -Name chrome | Format-Table -Property cpu,id CPU Id --- -- 36441.265625 484 5163.09375 656 303.5625 764 Let's see what processes consumed the CPU most! PS> ps chrome | sort cpu -descending | select -first 3 Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName ------- ------ ----- ----- ------ -- -- ----------- 1186 317 1876160 1055016 88,462.64 10524 1 chrome 1023 88 1825008 668684 37,740.92 6128 1 chrome 362 80 155776 64560 36,848.00 484 1 chrome As you can see, I can simply specify the column name(s). This is probably why many Linux commands have detailed options to limit displayed information. For example, `uname` has -s, -r, -m, -p, and many others that are just portions of -a. If it were in PS there would be no other options than -a and users could utilize it accordingly. Likewise `ps` has many options just to control the output which is again not necessary in the PS's side. Also due to the probable scripts that may be reliant on the column orders (e.g. my script assumes the third column to be always the one I wanted, because I hard-coded `awk {print $3}` in there), it is very hard to change the layout of the output in Linux commands. In PS there is no layout in the first place, so this backward compatibility concern doesn't exist. 2. Command names are much clearer. Many names are pretty descriptive so I don't have to remember the exact abbreviated forms, but at the same time they provide shorter aliases. For example `Get-Process` can also be called `ps`. bash/zsh can also benefit from this by manually assisning aliases, but I believe "sane defaults" should be long-descriptive names first, and abbreviated forms later. 3. Much more objected-oriented design. Say for example you want to get the last modified date of a file. In Linux I'd use `stat` and somehow extract information from it. Or, `stat` may have some option to print mtime so I may have to google for it. In PowerShell, I can use this instead: $file = Get-Item C:\Windows\notepad.exe $file.LastWriteTime This also applies to the process example above: $processes = Get-Process -Name chrome $processes[0].CPU All of these are benefited by tab completion, so you can easily find what properties any object has. This greatly improves discoverability, so that I don't need to rely on documentations (man pages on Linux, MSDN on Windows). Not only that, but PS is much closer to a general-purpose programming language than bash/zsh. It has built-in calculations (no need to rely on expr/bc), and it even has some basic type safety, such as: PS> 1 + 2 3 PS> 1 + "a" Cannot convert value "a" to type "System.Int32". Error: "Input string was not in a correct format." + 1 + "a" + ~~~~~~~ + CategoryInfo : InvalidArgument: (:) [], RuntimeException + FullyQualifiedErrorId : InvalidCastFromStringToInteger which might be silently ignored in bash/zsh in most cases. As you can see it even has fixed-width integer types (Int32), which is rarely seen in dynamic languages! When the logic of my scripts got complicated, I tended to abandon shell scripts and start programming in Python. But after learning PowerShell I'm starting to have a confidence that typical workflows can be implemented in PowerShell, in a readable way. I even think that PS can be utilized as a general-purpose programming language, like, "Python without dependencies", because PS is installed by default on Windows nowadays. Whoa, my response got unintentionally huge O.o. Hope this helps anyone.
hashhar 10y ago
For one, I can do away with all of the text parsing that is prone to breakage in case a tool changes their output somewhat (or god help me - tools that can't handle unicode properly). The power of bash actually comes from the GNU coreutils and other userland software. It has almost very little to with bash. Try out bash on a busybox and feel the crippled effect.
- AnonymousPlanet 10y ago
  So you mean PS as a scripting language, not as a shell, is superior. That's not a surprise, since it's newer and designed to do away with many annoyances of Bash. As a shell, however, it is sadly just slightly more usable as the REPL of, e.g., Python.
dragonwriter 10y ago
PS is great if everything you are dealing with is built for the .NET ecosystem. It's less great otherwise. This makes it often great for working on Windows, and definitely great for working with Windows and other MS software that is designed for the .NET/PS world.
- will_hughes 10y ago
  Perhaps, but I find it very easy to interact with various webservices. We use powershell to call API methods on our load balancers, change AWS configuration, change DNS records and a variety of other things.

by chmln 10y ago

> the experience of using PS was superior to that of bash As a Linux dweller, I'm genuinely curious about this one. I've found PS inferior in just about any use case.

thomas11 10y ago

I've used both extensively and I think they are fairly different, with different strengths and weaknesses. Bash is more pragmatic and more concise on the command line. PS is more uniform in its design and nicer for scripting IMO. It allows passing objects through pipes, has built-in JSON reading and writing, built-in parameter handling with defaults, mandatory and optional params, switches etc., and such niceties.

majkinetor 10y ago
Bash is not more concise, its other way around, of course, if you use default aliases. The reasons is logical - you almost never use text parsing in Posh while you almost never have anything without it in bash.
- AsyncAwait 10y ago
  I find Powershell non intuitive to learn honestly, Bash just clicks with me way more for some reason.

majkinetor 10y ago

I used majority of mainstream shells and Posh is a scpace ship compared to any other in existence. I wont reiterate again and again why, there are planty of places eihter on HN, reddit or SO why is it so. I guess you will have to give it a serious try.

jciochon 10y ago

I go back and forth between windows/unix for my day job and I also would be curious on any actual bullet points. I find that even in a situation where PS could potentially prove more useful or has an extra feature, what you end up with is a new set of chrome tabs open just to try and figure out how to do the thing. I suppose this might(?) be mitigated if you're embedded in the .NET world, but I just can't seem to get the memory down for the silly cmdlet naming and since they also have the admittedly interesting object-piping thing going on, you're always battling two pain points at a time instead of just one (e.g. syntax/naming in bash)

WorldMaker 10y ago
One of the best bits of PS1 advice I've seen was to get used to the Verb-Noun naming pattern [1] and in particular, the discoverability of the very standardized set of verbs [2]. Once you can guess the verb you want, then it can often be a simple matter of finding the right noun, and often nouns will be useful in sets similar to verbs. Get-Verb, Get-Command, and Get-Help are all quite useful for looking for a command. For dealing with the object pipeline I tend to find ConvertTo-Json very handy because as a developer I'm already quite used to reading objects in JSON already. (ConvertFrom-Json can similarly be used to bootstrap a PS1 pipeline with test data or remote data.) [1] https://blogs.technet.microsoft.com/heyscriptingguy/2012/05/14/discover-the-easy-way-to-begin-learning-windows-powershell/ https://blogs.technet.microsoft.com/heyscriptingguy/2012/05/... [2] https://msdn.microsoft.com/en-us/library/ms714428(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/ms714428(v=vs.85).a...

yokohummer7 10y ago

I had been a full-time Linux (desktop) user for more than 10 years, and only recently made a transition to Windows. As I'm nowhere proficient at using PowerShell I might be overrating it a bit, as the grass is always greener on the other side. Anyways, what I found to be satisfying while using PS were: 1. The input/output is done using objects. I know that "inter-process communication should be done with text" is the UNIX philosophy, and I appreciated that when using Linux, but after using PS I started to have mixed feelings about that. When using bash/zsh, I typically used awk to extract the data I wanted from the text emitted by an external process. Doing so isn't hard, mostly as simple as using `awk {print $3}` or something like that, but it is still a bit annoyance and more importantly, vulnerable to the changes in the output format. PS cmdlets communicate with themselves using objects, so it is very easy to extract some columns out of the command results. For example, when I query about a process in PS: PS> Get-Process -Name chrome Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName ------- ------ ----- ----- ------ -- -- ----------- 362 80 169636 109896 36,411.16 484 1 chrome 497 113 274988 132544 5,161.00 656 1 chrome 404 84 87444 55356 303.56 764 1 chrome If I want to extract CPU time and process ID: PS> Get-Process -Name chrome | Format-Table -Property cpu,id CPU Id --- -- 36441.265625 484 5163.09375 656 303.5625 764 Let's see what processes consumed the CPU most! PS> ps chrome | sort cpu -descending | select -first 3 Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName ------- ------ ----- ----- ------ -- -- ----------- 1186 317 1876160 1055016 88,462.64 10524 1 chrome 1023 88 1825008 668684 37,740.92 6128 1 chrome 362 80 155776 64560 36,848.00 484 1 chrome As you can see, I can simply specify the column name(s). This is probably why many Linux commands have detailed options to limit displayed information. For example, `uname` has -s, -r, -m, -p, and many others that are just portions of -a. If it were in PS there would be no other options than -a and users could utilize it accordingly. Likewise `ps` has many options just to control the output which is again not necessary in the PS's side. Also due to the probable scripts that may be reliant on the column orders (e.g. my script assumes the third column to be always the one I wanted, because I hard-coded `awk {print $3}` in there), it is very hard to change the layout of the output in Linux commands. In PS there is no layout in the first place, so this backward compatibility concern doesn't exist. 2. Command names are much clearer. Many names are pretty descriptive so I don't have to remember the exact abbreviated forms, but at the same time they provide shorter aliases. For example `Get-Process` can also be called `ps`. bash/zsh can also benefit from this by manually assisning aliases, but I believe "sane defaults" should be long-descriptive names first, and abbreviated forms later. 3. Much more objected-oriented design. Say for example you want to get the last modified date of a file. In Linux I'd use `stat` and somehow extract information from it. Or, `stat` may have some option to print mtime so I may have to google for it. In PowerShell, I can use this instead: $file = Get-Item C:\Windows\notepad.exe $file.LastWriteTime This also applies to the process example above: $processes = Get-Process -Name chrome $processes[0].CPU All of these are benefited by tab completion, so you can easily find what properties any object has. This greatly improves discoverability, so that I don't need to rely on documentations (man pages on Linux, MSDN on Windows). Not only that, but PS is much closer to a general-purpose programming language than bash/zsh. It has built-in calculations (no need to rely on expr/bc), and it even has some basic type safety, such as: PS> 1 + 2 3 PS> 1 + "a" Cannot convert value "a" to type "System.Int32". Error: "Input string was not in a correct format." + 1 + "a" + ~~~~~~~ + CategoryInfo : InvalidArgument: (:) [], RuntimeException + FullyQualifiedErrorId : InvalidCastFromStringToInteger which might be silently ignored in bash/zsh in most cases. As you can see it even has fixed-width integer types (Int32), which is rarely seen in dynamic languages! When the logic of my scripts got complicated, I tended to abandon shell scripts and start programming in Python. But after learning PowerShell I'm starting to have a confidence that typical workflows can be implemented in PowerShell, in a readable way. I even think that PS can be utilized as a general-purpose programming language, like, "Python without dependencies", because PS is installed by default on Windows nowadays. Whoa, my response got unintentionally huge O.o. Hope this helps anyone.

hashhar 10y ago

For one, I can do away with all of the text parsing that is prone to breakage in case a tool changes their output somewhat (or god help me - tools that can't handle unicode properly). The power of bash actually comes from the GNU coreutils and other userland software. It has almost very little to with bash. Try out bash on a busybox and feel the crippled effect.

AnonymousPlanet 10y ago
So you mean PS as a scripting language, not as a shell, is superior. That's not a surprise, since it's newer and designed to do away with many annoyances of Bash. As a shell, however, it is sadly just slightly more usable as the REPL of, e.g., Python.

dragonwriter 10y ago

PS is great if everything you are dealing with is built for the .NET ecosystem. It's less great otherwise. This makes it often great for working on Windows, and definitely great for working with Windows and other MS software that is designed for the .NET/PS world.

will_hughes 10y ago
Perhaps, but I find it very easy to interact with various webservices. We use powershell to call API methods on our load balancers, change AWS configuration, change DNS records and a variety of other things.