How about if you just give them the man page for "find" and the /? page for "dir" and see who can get the command correct first?

Looks like "find" is yet another command with the Examples section at the very bottom. I suppose that's the convention or something, but sometimes I do run into a man page with the examples at the top, and it takes a lot of effort not to jump up and shout "Thank you!" loud enough for the author to hear me.

The brain is a powerful inference engine. A few well-chosen examples can teach 95% of normal people 95% of what they need to know (numbers pulled out of my butt, 2016). Put good examples at the top and marvel at how many more people actually seem like they RTFM.

And if we're going to be using the commandline, I'd much rather the unixy

    find PATH -name FOO

than the powershelly

    Get-ChildItem -Path PATH -Filter FOO -Recurse

I mean "dir FOO /s" is simple and all, but powershell was created because cmd was deficient in many areas.

The blogpost referenced in the article is also stacking the deck a bit, as some of the 'complex' commands are normal commands, but with the verbosity turned up - the rsync command has three flags for increasing verbosity...

    ls -r PATH FOO

if you want things to be short. Since parameters can be often given positionally instead of named and you can shorten parameters as long as they remain unambiguous and there are aliases – it seems like you're stacking the deck a bit as well.

PowerShell has over cmd (and WSH):

- Consistency in command handling, naming and discoverablity

- A robust scripting language

- A modern shell

- An embeddable scripting environment (most GUI configuration stuff on Windows Server these days is PowerShell in the background; PowerShell is also the NuGet console in VS)

- Extensible

- The core of the language is built up from mostly orthogonal commands which work completely the same regardless of the context

- Interoperable with native commands, .NET, COM, WMI, arbitrary item hierarchies (file systems, registry, etc. – comes back to consistency and the point above)

- SSH-like capabilities built-in. Running a command or a series of commands over hundreds of machines is no harder than doing it locally.

The (perceived) verbosity can usually be tamed quite a bit with aliases and shortening parameters (or using them positionally), which is what you'd do most of the time when working with the shell once familiar with it. I guess you're not yet familiar with PowerShell or never used it, and that's okay. Because the long commands are in many, many cases self-describing to the point that you don't have to guess at all what they mean or do. This also helps with learning or communicating with others.

> I guess you're not yet familiar with PowerShell or never used it

This is correct - my example wasn't intentionally complex, but the result of googling and looking at the top answers (cmd was deficient, and I was wondering how you'd do the same thing in the 'proper' windows shell). I'm glad I have got the responses I did - I didn't mean to deride powershell, but show that if you want more power, you end up with more complex commands - and at the cli, I'd rather be typing in the unix example that the powershell one.

In any case, powershell should be better than the other shells we're talking about - it's from 2006, and the others are considerably older.

> powershell was created because cmd was deficient in many areas

And we didn't just copy bash, because bash was deficient in many areas.

On the other hand, the power shell version returns objects that can be manipulated in a safe way, whereas the find version relies on "-exec" being a feature of find (Talk about bloat.), which is string-based (if you're not extra careful: breaks with spaces/tabs/newlines/semicolons/dollars/backslahes/... depending on what you use it for) and spawns one process per file (really inefficient).

or

    ls -Recurse -Filter FOO PATH

I actually do this instead:

    find . | grep "\.txt$"

once you mentioned it, the original commands which are compared are not equivalent. Dir does case insensitive search, find is case sensitive. The equivalent would be:

  find . | grep -i "\.txt$"

You can do a case insensitive search with -iname: find . -iname "*.txt"

Neither, they would search in Finder or Explorer.

It's funny how minds differ. As a kid I was mesmerized by globbing and pipe operators. GUIs didn't have the same magic appeal. The List monad was calling me from the future past.