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.
find . -type f -name '*.html' -exec cp {} /home/new_dir/{} \;
If you know a simpler way in powershell please post it though. 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.
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)
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.
> 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.