Hacker News Reader

Comment by chmln | Hacker News Reader

> 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.

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.

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.

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.

You seem to have articulated all my thoughts perfectly.

The thing about parsing text is a very huge pain point for me because I've had some tool change their output (and unicode issues) which broke some scripts.

The structured nature of PS makes it very powerful and allowed me to write a script that checks the latest versions of some software upstream and tells me if there are updates. I have that on bash as well but it's comparatively unmaintainable.

i agree with the fact that PS object oriented communication between commands is much better then text. But I disagree about your point (2) saying that command names are more discoverable. with linux style conventions, there is a hierarchy that helps you navigate between command's features. for example `docker image ls` you can type docker, see that there is an images subtree, type docker images, see that there is an ls command, and run it. With Powershell you kind of have to guess and type `get-docker` and tab through commands. Also some times the verb is not easy to guess. So in terms not relying on documentation as you called it, I think PS is worse. That being sayd, once you do know the command you need, using it is much easier with PS as you nicely described. tip - if you liked tab completion, try ctrl+space :)

I was thinking more about the "proper noun" aspect of the UNIX commands. I mean, what do `awk`, `sed`, `tar`, `xargs`, `df` mean? Why does `free` only print the remaining memory, not the disk space? Why is `top` even related to processes? They are all like that because Unix has had a long way until today. In the beginning `grep` would have been enough, but suddenly someone wanted to improve the state of affairs, and made a new command named `awk`. Probably there had only been `ar`, and then later the necessity of `tar` was found. `free` is not `mf` and `df` is not `free`, because the original designer thought the free space of the main memory was more important. All these inconsistency/idiosyncrasy do make learning the UNIX command hierarchy harder. We developers don't feel that way because we all are very used to such commands, but there might be some memory in our inside when we tried really hard to memorize all of the useful commands just to do basic things.

PowerShell didn't have this backward compatibility concern so it built up its own vocabulary from the scratch. While it is nowhere near to perfect (as your example shows, the VERB-NOUN naming scheme can be a bit cumbersome when some functionalities need to be grouped), I'd say it is at least much more consistent regarding basic file/device management, because there was simply no baggage to consider when they designed PowerShell for the first time.

Ah, and thanks for suggesting `Ctrl-Space`! I thought it would have been better if PowerShell had a GUI widget listing possible candidates, so I was considering sending a patch. It turns out that the MS people are definitely more clever than me. :)

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.

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.

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.

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)

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/...

[2] https://msdn.microsoft.com/en-us/library/ms714428(v=vs.85).a...

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.

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.

I find Powershell non intuitive to learn honestly, Bash just clicks with me way more for some reason.

Reply on news.ycombinator.com