I learned C# with a big fat book, and the command line compiler... I understand the usefulness of command line applications.

However, when I need more than what a simple shell script gives me, I'm more inclined to reach for node, ruby or python than C#/.Net ... the overhead for a quick scripting environment is quite a bit lower than having to setup a project and build requirements. I've done both...

Why node, is simply npm... create a directory, npm init, write my script, etc. reference it from an alias or .cmd in my ~/bin directory (added to my path). Then it works in windows, mac and linux which I use all regularly. PS is mostly windows.

Have you ever written a commandlet ? This is my point, regardless of how you feel in PS vs Bash or Python vs C# - exposing your application logic trough commandlets is incredibly simple and powerful - much simpler than doing a CLI app in other languages even with argument parsing frameworks in python and likes, commandlets let you pipe and return/accept .NET objects.

So my comment isn't PS everything or C# everything, it's if you're using C# to write a big fat monolithic app that has multiple isolated functionalities you can expose those fairly easily with PS.

I'm a .net developer, I still install cygwin/bash on my computer because I can write stuff quicker and better. PS get's incredibly verbose for anything non trivial. I learned powershell long before bash too.

Calling Powershell incredibly verbose is about the same as calling C# incredibly verbose.

Sure, perhaps they're not as compact as some of the incredibly information-dense perl scripts that people come up with.

I'd wager though that it's easier to understand what a random powershell script is doing than a random perl or bash script that pipes output throgh a dozen utilities.

I've got an example of powershell getting verbose here: http://flukus.github.io/2015/03/13/2015_03_13_Powershell-is-... . Ignore the rest and look at the example where I'm trying to copy a directory recursively and with a filter. In bash the same task is a relatively simple one liner:

  find . -type f -name '*.html' -exec cp {} /home/new_dir/{} \;

If you know a simpler way in powershell please post it though.

Well, how about this:

  ls . -r -file -fi *.html | cp -d /home/new_dir/

It is a bit shorter than your bash equivalent, still doing the same thing.

I think you're mistaken about what `cp` (`Copy-Item`) is intended to do. Its main purpose is to copy, not to filter. Yes, `Copy-Item` supports filtering because it's part of the "common parameters", but to be more in line with the cmdlets' original purposes, you should `ls` (`Get-ChildItem`) first, because it has more filtering capability, and then pipe the results to `cp`.

Is it complex? No, actually its complexity is exactly the same as that of your `find` example! `find` is more or less equivalent to `ls` in that both gathers the list of files that meet certain criteria. And then, like `find` invokes `cp` multiple times to do actual copying, `ls` (`Get-ChildItem`) feeds its result to `cp` (`Copy-Item`). They are structured in a similar way.

I'd even say the PS one-liner is more akin to "the UNIX philosophy". In the bash one-liner, there is a direct parent-child relationship between `find` and `cp`, which doesn't utilize pipes at all. Whereas the PS one-liner connects two equivalent processes (`ls` and `cp`) with a pipe. This is exactly what I'd call "small processes work together to get the job done", which is again the UNIX way.

Well yes, that's an example that's relying on the find utility, for which the equivalent in the windows world (at least for file management) is robocopy.

    robocopy /r $pathFrom $pathTo *.html 

If you wanted to exclude say 'main.js' then it'd be:

    robocopy /r $pathFrom $pathTo *.html /xf main.js 

..and /xd is for excluding directories too.

I guess copy-item should be smarter to be able to handle this.

Also, for what it's worth, your example in the linked post is a bit more verbose than it really needs to be. You're comparing a full-up programming language to nant there. So yeah, it's a bit more verbose there. But I bet I can come up with a counter-example where nant is a giant nightmare to get right (or requires just dropping straight to executing external commands) (There's a reason I've killed off all usage of nant years ago, and gone to powershell for build scripts)

Perl scripts can be vastly more powerful than PS. Perl is a full blown general purpose programming language with a massive collection of libs and frameworks.

It is however very powerful that Perl can be used in bash pipelines. But that is also true for any Unix tool that takes I/O.

So Bash is also very powerful with the help from all its friends that can be used with pipes. Shell native.

And you don't HAVE to code Bash in the most convoluted way possible. Sane code structure and naming goes a long way.

> Perl is a full blown general purpose programming language with a massive collection of libs and frameworks.

> So Bash is also very powerful with the help from all its friends

> you don't HAVE to code Bash in the most convoluted way possible. Sane code structure and naming goes a long way.

All of these things are also true for Powershell. Powershell can use any .NET Assembly, and if necessary make native windows system calls too if you really want.

Haven't really touched Windows the last 5+ years but adding .NET to the mix sounds a bit complicated in relation to Bash.

Like I said above, my point was that PS lets you expose your app logic a lot easier than writing a CLI for it.

I've been dabbling with PS (using it as my primary console) but my workflow just isn't that complex, so I don't have a compelling reason to write cmdlets (yet!).

Can you recommend a good tutorial?

I've used MSDN docs but I wouldn't call that a tutorial :)

The msdn docs are great, it's just difficult to navigate them. Perhaps this would help? https://msdn.microsoft.com/en-us/library/dd878294(v=vs.85).a... There's tutorials in there as well, but I didn't find them very useful compared to the overview/concepts documentation.

Yeah that's what I went trough as well but usually tutorials are shorter and more to the point, this is more reference/in-depth style - I'm guessing OP was looking for something along those lines.