9 ms·

Not that I have much to add here, but as a complete non-techie PowerShell seems amazingly powerful for this use. I went from having no knowledge at all to havi

Not that I have much to add here, but as a complete non-techie PowerShell seems amazingly powerful for this use. I went from having no knowledge at all to having written a web scraping function and checked 7000 sites for a specific phrase in less than two hours. It was the most intuitive piece of technology I've ever used.

simooooo 9y ago
are you nuts? its about 10x harder to use than c#, and twice as hard to debug. I've come to the conclusion that its just better to write a small c# app than try and use powershell
- czechdeveloper 9y ago
  They just have different places. I use both and really Powershell is not 10x more difficult. It's just different language with different goals.
- 13of40 9y ago
  You're not comparing your 1000th day of C# programming to your first day of PowerShell programming by any chance, are you?
  - simooooo 9y ago
    About 100 to 1.
- Dolores12 9y ago
  There are people that need not debug.
- c0wb0yc0d3r 9y ago
  I agree that powershell can be hard to debug but I would not say that C# is exactly easier to use. Some cases sure, but when it comes to machine management especially, powershell destroys C#. Another example of powershell being superior to C# would be ist ability to interact with RESTful APIs and parsing JSON (see Invoke-RestMethod ConvertFrom-Json, and ConvertTo-Json). Not saying that it can't be done in C#, but definitely far easier in powershell.
  - braveo 9y ago
    Powershell works well as a shell, but fails specacularly as a programming language. The whole "I can run this script on 100 different machines at once super easy" is fine, but lets see you try to write some rigorous code in PS and the come back and tell me how it's easier than C#. They both have their place.
    - Arnavion 9y ago
      I once took over a certain repository that builds a dozen or so disparate external libraries with dependencies between themselves. The original developer of the repository did it by manually remembering which library had which dependencies and running .bat scripts to build them in order. When I took over it, I wrote a PS script to automate the whole build. The script contains a description of each library's dependencies, so it knows what order to build all the libraries in. Each library is built in its own "job" using Start-Job, so the builds are also maximally parallelized; the script is essentially a loop of two functions: `for each library -> if library's dependencies have all been built -> start parallel job to build library` and `for each job -> if the job has finished -> mark the library as built`. I would not write it in C#. Most of the build steps for each library involve running other processes, so using a shell DSL rather than multiple Process.Start()+Process.WaitForExit() is convenient. Even things like copying files is more convenient using Copy-Item than C#, especially since the PS versions support globs. I would hope a build tool counts as both rigorous code as well as justifies PS as a programming language. Aside: The repository was forked by some other people who did not like / could not read PS, so they rewrote it in Python. The Python version is several times larger than the PS version, though to be fair to it it's also more generic and has more features. A lot of that verbosity though does come from the more verbose code for spawning processes from Python compared to PS.
      - arghimonmobile2 9y ago
        Soooo... you reimplemented GNU Make?
        9y ago
- jug 9y ago
  The beautiful part about Powershell is that it's object oriented so that it doesn't depend on "plain" textual output formats. Something like a bash command line and piping text outputs, struggling with regexps in awk or whatnot while crossing your fingers no update will break your scripts felt pretty archaic and a wrong way to go about it when I had started to get more fluent in PS. (which btw is OSS and available on Linux now too) But the worst thing I came across with Powershell is this. The fricking return semantics. http://stackoverflow.com/questions/10286164/function-return-value-in-powershell http://stackoverflow.com/questions/10286164/function-return-...
- throwasehasdwi 9y ago
  I second this. Powershell syntax is almost as bad as Bash. I have no idea why they didn't just make a command-line version of C#, it's a far better designed language.
  - oneZergArmy 9y ago
    It's made for sysadmins like me who think C# is too hard.
    - throwaway7645 9y ago
      Or the kind of programming you do at work is easier solved by short scripts such as Perl, Python, PS, Bash, or Batch instead of something like Java where one has to write a lot of scaffolding.
  - dahart 9y ago
    Bash and Powershell are shells, they are command languages, and not programming languages like C#. That distinction, while in many ways subtle with tons of overlap, is the primary factor in shell syntax being crappy as a "language" -- it's because command evaluation is (necessarily) prioritized over language design. There is a good reason that no shells exist that have a "better designed language." As well as good reasons that no well designed programming language makes a good shell. They solve different problems, and I don't think C# would make a good command shell without significant syntax compromises.
    - thaumasiotes 9y ago
      > There is a good reason that no shells exist that have a "better designed language." As well as good reasons that no well designed programming language makes a good shell. Where does tcl fit into things for you?
      - dahart 9y ago
        Hmm good question! It's been a very long time since I used tcl/tk, but I just gave myself a 2 minute refresher and browsed the docs. I would say Tcl is a programming language, not a system shell. The tcl tutorial concurs, calls tcl specifically a 'dynamic programming language', and compares tcl to python. I'm definitely using 'shell' and 'command' in a narrow sense. I meant to add contrast between PowerShell and C#, by calling one a command shell and the other a programming language. But both words have been used with much broader meanings. So I'll try to be a little more careful and say that what I'm really talking about is a system shell and system commands, where a system command means direct access to executable files on the system, and system shell means an interpreter that provides system commands. Even though Tcl stands for 'command language', it's not talking about system commands using the same distinction I made above. Tcl's use of "command" is referring to programmer-defined functions & API, and it is not referring to system commands. Tclsh is a shell, but I wouldn't call that a system shell like PowerShell or bash. It is an interactive tcl interpreter, but not really a system shell. Tclsh isn't something sysadmins would typically use, right? Perhaps the defining characteristic of a system shell (as opposed to a programming language) is system commands; running executable files on the system can be done by typing the bare name of the file, without any other syntax in the way. That is true in powershell and bash, and not true in C#, tcl, python, etc. To run a system command in tcl, you have to use 'exec' or 'open', you have to use 'glob' to get file completion, and there's required programming language syntax frequently involved in passing arguments. In tcl you have to use $env(var) or $::env(var) to get an environment variable rather than $var. Those are the kinds of things that shells provide with little or no syntax, and exactly the kind of stuff that begins to compromise language syntax and language design in favor of promoting system commands to first class status. BTW, you got me curious about tcl again. I never used it enough to get a sense of what it's best used for. What kinds of things would you use tcl for yourself? Do you like to use it for system shell tasks instead of bash? (I know there are certainly legit reasons to do that.) What kinds of programs would you start in tcl?
- joeyaiello 9y ago
  PM on PowerShell here: if you have any of those small C# apps handy, I'd love to take a look at them to see what you're doing that's difficult in PowerShell. Similarly, we're trying to make some improvements to debugging right now with PowerShell 6.0 [1] (the one that's cross-plat and built on .NET Core), and I'm very interested in hearing your feedback on how we can do a better job there. Even if it's "fix your docs" or "too hard to learn", that's great info, especially coming from a C# guru. [1]: https://github.com/powershell/powershell/issues?utf8=%E2%9C%93&q=label%3AArea-Debugging%20 https://github.com/powershell/powershell/issues?utf8=%E2%9C%...
  - c0wb0yc0d3r 9y ago
    If I could make a suggestion about debugging scripts. It doesn't seem that I can currently debug scripts that are contained in a module folder, but not directly the script being called. If I have a module file that looks like this: Get-ChildItem -Path $PSScriptRoot\.ps1 | ForEach-Object{ .$_.FullName } # source the script files Export-ModuleMember -function -* # export those sourced scripts I am not sure how it works exactly, but if I am writing a new cmdlet, Get-HackerNews.ps1, the breakpoints aren't hit in ISE. It would be super cool if it did. ------ Also is there guidance on module structure? Right now it looks like the docs indicate that all the cmdlets should be placed in the .psm1 file, but to me that sounds like it would get rather unmaintainable very quickly. Just looking at the one my dev team has created, we have nearly 50 exported functions. Maybe our our module could be broken up, but that would still leave us ~10 cmdlets per module.
    - hobs 9y ago
      Here is an example of a real project that uses PowerShell to help DBA automation, you dont include them in your psm1, just dot source them, see https://github.com/sqlcollaborative/dbatools/blob/master/dbatools.psm1 https://github.com/sqlcollaborative/dbatools/blob/master/dba... for an example.
      - c0wb0yc0d3r 9y ago
        Awesome, that is similar to what I do right now.
- nthcolumn 9y ago
  Agree - I find the thing incomprehensible without some sort of intellisense running (which I abhor I tell you abhor!) seems arcane and weird to me and much prefer c# but "WHY ARE ATTACKERS USING POWERSHELL?" - simply because its already there probably? And cmdlets are a bit like nmap scripts - if you can read lua you can probably spitball them together. I'm not sure that ps is amazingly more powerful - just all we before was .bat from hell and debug sadly gone now...
- Scaevolus 9y ago
  Sometimes it's better to write something in a more advanced language, but for small tasks it's hard to beat the overhead of a shell! There are crossover points (varying by person) where a scripting language is preferable to a shell, and where a strongly-typed language is preferable to a dynamically-typed language.
  - throwaway7645 9y ago
    PowerShell is a scripting language though, but it can also be used as a shell. The syntax is more advanced now that it has classes...etc.
- InclinedPlane 9y ago
  I wish I could give out a prize for comments like this. "I tried to use X language casually for a few days and didn't like it, it must objectively suck!" PowerShell isn't 10x harder to use than C#, how do I know that? Because many people use PowerShell regularly in their day to day jobs, and do so quite successfully. Most people who actually use PowerShell don't complain about how hard it is. It is harder than C# to debug, probably more than twice as hard, actually. Does that make it impossible to program in? Hardly. There are tons of other languages that are roughly equally difficult to debug, especially many of the dynamic languages: PHP, Python, etc. People have been building things of tremendous value with hard to debug languages for ages. The fact that C# has such a good debugging story is great, but it's not the end-all be-all of a language. Also, PowerShell has some significantly advanced debugging tools compared to a lot of other dynamic languages.
  - ams6110 9y ago
    Different strokes. Different people grasp concepts differently. I can say that every programming language that I grew to love, I liked almost immediately. The ones that make no sense from the get-go, I don't spend much time on.
    - JadeNB 9y ago
      > I can say that every programming language that I grew to love, I liked almost immediately. The ones that make no sense from the get-go, I don't spend much time on. Surely the second sentence is the reason for the first? If you don't give languages that make a bad first impression a second chance, then you have no idea whether you would have grown to love one of them. (Certainly you aren't obliged to find out, but to regard this as evidence that you wouldn't have liked them I think is reversing causality.)
- drak0n1c 9y ago
  He said "as a complete non-techie".
- yks 9y ago
  I started using F# scripts instead of PowerShell or compiled C#. Just got to copy Fsi.exe and a few other dlls onto the target machine for it to work.
chubot 9y ago
Do you have an example of that? I'm curious how PowerShell is better than other languages for this type of problem. Does it just have good built-in parallelism?
- Numberwang 9y ago
  You can see my entire thinking outlined in my reddit thread. https://www.reddit.com/r/PowerShell/comments/5f4r10/web_scraping_newb_question/ https://www.reddit.com/r/PowerShell/comments/5f4r10/web_scra... I miss-remembered the number of sited scraped but it's all the same. There is no parallelism (I really really am a complete non-techie) but actually in this case I didn't want to hammer away as the sites were all under the same domain and I imagine there might be trouble (which I why I also played it very safe and added the pause). I know there are better and smarter ways of doing things and I did further modifications and experiments after my thread, but in any case, I had a task and was able to quickly complete it in PowerShell starting from absolute 0.
- joeyaiello 9y ago
  Disclaimer: I'm a PM who works on PowerShell at Microsoft There's a bunch of 3rd-party modules out there that do a great job of offering parallelism[1][2][3], and we also support the notion of "PowerShell Jobs"[4] (which one or two of those third-party implementations actually build on to achieve what they're doing). However, we decided that strong parallelism support is important enough to build into the language, so we're mulling on a first-party design. If you're interested, we've got an RFC out where we're looking for feedback on the parallelism/concurrency design.[5] [1]: https://www.powershellgallery.com/packages/PSParallel/ https://www.powershellgallery.com/packages/PSParallel/ [2]: https://www.powershellgallery.com/packages/SplitPipeline https://www.powershellgallery.com/packages/SplitPipeline [3]: https://github.com/RamblingCookieMonster/Invoke-Parallel https://github.com/RamblingCookieMonster/Invoke-Parallel [4]: https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.core/about/about_jobs https://msdn.microsoft.com/en-us/powershell/reference/5.1/mi... [5]: https://github.com/PowerShell/PowerShell-RFC/issues/85 https://github.com/PowerShell/PowerShell-RFC/issues/85
  - 9y ago
dkhenry 9y ago
PowerShell is a little bit more difficult then something like Python or a well equipped Bash shell, but the fact that you can do it shows how much progress it has made
- IshKebab 9y ago
  I would say nothing is much less intuitive than a Bash shell. Maybe the Git CLI. But Bash is spectacularly unintuitive. How do I rename files? `mv`? List files is `ls`? Why not `list`? What the hell does `2>&1` even do?! Have you ever looked at the escaping options of `ls`? How do I end a for look? `fi`? WTF kind of a weird joke is that? If you're thinking "but... it's all so obvious. What is this guy talking about", ask yourself how long ago you first typed a shell command. Can you even remember how hard it was to learn? For me it was something like 15 years and I actually can remember because it made such an impression on me how terrible a system it was. (That and X86Config if you remember that insanity.) Even though it was awful to learn, it feels totally easy and 'intuitive' to me now. But that's just because I use it so much. It's not intuitive. Don't fall into the old curmudgeon trap of thinking the thing that you find trivial through experience is actually good. /rant
  - jrochkind1 9y ago
    Maybe it's intuitive compared to whatever else there was in the 70s when the bourne shell was invented? I dunno. I agree, bash is not very intuitive to the contemporary scripter _especially_ when you get into scripting.
  - lottin 9y ago
    What were you using before? Compared to DOS the Unix shell actually seemed a very well designed system. There are a couple of things that are admittedly hard to grasp, redirection being one of them. But I have no problem with mv and ls. By the way, fi closes an if block. A for loop uses do and done.
    - richfnelson 9y ago
      In DOS you use `dir` to list files in a directory. You can also use `dir` to list files that match a string in a directory. `dir 1.png` would list all PNGs with a "1" in their name. You need a separate command with options and a flag to do that in bash. In DOS, it's less than a dozen characters, and it's far more intuitive than having to use `find`. Sure, `find` and `ls` might be more flexible, but definitely not more intuitive.
hackunomatter 9y ago
A judicious use of xargs, curl and grep would have done it in 1 line in Linux. I looked at your PowerShell code; that does look a bit complicated compared to what Linux offers.
- Numberwang 9y ago
  I'm sure you are right. I was just trying to convey the positive impression I got from what little time I spent with PowerShell and the great documentation it has. Especially the fact that I was able to accomplish what I set out to do in a very reasonable amount of time.
- Arnavion 9y ago
  You can do it in one line in PS too. $sites = @('https://www.google.com/', 'https://www.example.com/') $searchString = 'oogle' $sites | %{ if ((iwr $_).Content -like "*$searchString*") { "$_;OK" } else { "$_;NOT OK" } } > C:\temp\output.csv
shallot_router 9y ago
As a security analyst/engineer, PowerShell is both one of my favorite (for collecting information, forensics, administrating and protecting, etc.) and least favorite (because practically every day we're fending off malware using different PowerShell techniques we have to detect and mitigate, plus it's a favorite of APTs) tools.

simooooo 9y ago

are you nuts? its about 10x harder to use than c#, and twice as hard to debug. I've come to the conclusion that its just better to write a small c# app than try and use powershell

czechdeveloper 9y ago
They just have different places. I use both and really Powershell is not 10x more difficult. It's just different language with different goals.
13of40 9y ago
You're not comparing your 1000th day of C# programming to your first day of PowerShell programming by any chance, are you?
- simooooo 9y ago
  About 100 to 1.
Dolores12 9y ago
There are people that need not debug.
c0wb0yc0d3r 9y ago
I agree that powershell can be hard to debug but I would not say that C# is exactly easier to use. Some cases sure, but when it comes to machine management especially, powershell destroys C#. Another example of powershell being superior to C# would be ist ability to interact with RESTful APIs and parsing JSON (see Invoke-RestMethod ConvertFrom-Json, and ConvertTo-Json). Not saying that it can't be done in C#, but definitely far easier in powershell.
- braveo 9y ago
  Powershell works well as a shell, but fails specacularly as a programming language. The whole "I can run this script on 100 different machines at once super easy" is fine, but lets see you try to write some rigorous code in PS and the come back and tell me how it's easier than C#. They both have their place.
  - Arnavion 9y ago
    I once took over a certain repository that builds a dozen or so disparate external libraries with dependencies between themselves. The original developer of the repository did it by manually remembering which library had which dependencies and running .bat scripts to build them in order. When I took over it, I wrote a PS script to automate the whole build. The script contains a description of each library's dependencies, so it knows what order to build all the libraries in. Each library is built in its own "job" using Start-Job, so the builds are also maximally parallelized; the script is essentially a loop of two functions: `for each library -> if library's dependencies have all been built -> start parallel job to build library` and `for each job -> if the job has finished -> mark the library as built`. I would not write it in C#. Most of the build steps for each library involve running other processes, so using a shell DSL rather than multiple Process.Start()+Process.WaitForExit() is convenient. Even things like copying files is more convenient using Copy-Item than C#, especially since the PS versions support globs. I would hope a build tool counts as both rigorous code as well as justifies PS as a programming language. Aside: The repository was forked by some other people who did not like / could not read PS, so they rewrote it in Python. The Python version is several times larger than the PS version, though to be fair to it it's also more generic and has more features. A lot of that verbosity though does come from the more verbose code for spawning processes from Python compared to PS.
    - arghimonmobile2 9y ago
      Soooo... you reimplemented GNU Make?
      - 9y ago
jug 9y ago
The beautiful part about Powershell is that it's object oriented so that it doesn't depend on "plain" textual output formats. Something like a bash command line and piping text outputs, struggling with regexps in awk or whatnot while crossing your fingers no update will break your scripts felt pretty archaic and a wrong way to go about it when I had started to get more fluent in PS. (which btw is OSS and available on Linux now too) But the worst thing I came across with Powershell is this. The fricking return semantics. http://stackoverflow.com/questions/10286164/function-return-value-in-powershell http://stackoverflow.com/questions/10286164/function-return-...
throwasehasdwi 9y ago
I second this. Powershell syntax is almost as bad as Bash. I have no idea why they didn't just make a command-line version of C#, it's a far better designed language.
- oneZergArmy 9y ago
  It's made for sysadmins like me who think C# is too hard.
  - throwaway7645 9y ago
    Or the kind of programming you do at work is easier solved by short scripts such as Perl, Python, PS, Bash, or Batch instead of something like Java where one has to write a lot of scaffolding.
- dahart 9y ago
  Bash and Powershell are shells, they are command languages, and not programming languages like C#. That distinction, while in many ways subtle with tons of overlap, is the primary factor in shell syntax being crappy as a "language" -- it's because command evaluation is (necessarily) prioritized over language design. There is a good reason that no shells exist that have a "better designed language." As well as good reasons that no well designed programming language makes a good shell. They solve different problems, and I don't think C# would make a good command shell without significant syntax compromises.
  - thaumasiotes 9y ago
    > There is a good reason that no shells exist that have a "better designed language." As well as good reasons that no well designed programming language makes a good shell. Where does tcl fit into things for you?
    - dahart 9y ago
      Hmm good question! It's been a very long time since I used tcl/tk, but I just gave myself a 2 minute refresher and browsed the docs. I would say Tcl is a programming language, not a system shell. The tcl tutorial concurs, calls tcl specifically a 'dynamic programming language', and compares tcl to python. I'm definitely using 'shell' and 'command' in a narrow sense. I meant to add contrast between PowerShell and C#, by calling one a command shell and the other a programming language. But both words have been used with much broader meanings. So I'll try to be a little more careful and say that what I'm really talking about is a system shell and system commands, where a system command means direct access to executable files on the system, and system shell means an interpreter that provides system commands. Even though Tcl stands for 'command language', it's not talking about system commands using the same distinction I made above. Tcl's use of "command" is referring to programmer-defined functions & API, and it is not referring to system commands. Tclsh is a shell, but I wouldn't call that a system shell like PowerShell or bash. It is an interactive tcl interpreter, but not really a system shell. Tclsh isn't something sysadmins would typically use, right? Perhaps the defining characteristic of a system shell (as opposed to a programming language) is system commands; running executable files on the system can be done by typing the bare name of the file, without any other syntax in the way. That is true in powershell and bash, and not true in C#, tcl, python, etc. To run a system command in tcl, you have to use 'exec' or 'open', you have to use 'glob' to get file completion, and there's required programming language syntax frequently involved in passing arguments. In tcl you have to use $env(var) or $::env(var) to get an environment variable rather than $var. Those are the kinds of things that shells provide with little or no syntax, and exactly the kind of stuff that begins to compromise language syntax and language design in favor of promoting system commands to first class status. BTW, you got me curious about tcl again. I never used it enough to get a sense of what it's best used for. What kinds of things would you use tcl for yourself? Do you like to use it for system shell tasks instead of bash? (I know there are certainly legit reasons to do that.) What kinds of programs would you start in tcl?
joeyaiello 9y ago
PM on PowerShell here: if you have any of those small C# apps handy, I'd love to take a look at them to see what you're doing that's difficult in PowerShell. Similarly, we're trying to make some improvements to debugging right now with PowerShell 6.0 [1] (the one that's cross-plat and built on .NET Core), and I'm very interested in hearing your feedback on how we can do a better job there. Even if it's "fix your docs" or "too hard to learn", that's great info, especially coming from a C# guru. [1]: https://github.com/powershell/powershell/issues?utf8=%E2%9C%93&q=label%3AArea-Debugging%20 https://github.com/powershell/powershell/issues?utf8=%E2%9C%...
- c0wb0yc0d3r 9y ago
  If I could make a suggestion about debugging scripts. It doesn't seem that I can currently debug scripts that are contained in a module folder, but not directly the script being called. If I have a module file that looks like this: Get-ChildItem -Path $PSScriptRoot\.ps1 | ForEach-Object{ .$_.FullName } # source the script files Export-ModuleMember -function -* # export those sourced scripts I am not sure how it works exactly, but if I am writing a new cmdlet, Get-HackerNews.ps1, the breakpoints aren't hit in ISE. It would be super cool if it did. ------ Also is there guidance on module structure? Right now it looks like the docs indicate that all the cmdlets should be placed in the .psm1 file, but to me that sounds like it would get rather unmaintainable very quickly. Just looking at the one my dev team has created, we have nearly 50 exported functions. Maybe our our module could be broken up, but that would still leave us ~10 cmdlets per module.
  - hobs 9y ago
    Here is an example of a real project that uses PowerShell to help DBA automation, you dont include them in your psm1, just dot source them, see https://github.com/sqlcollaborative/dbatools/blob/master/dbatools.psm1 https://github.com/sqlcollaborative/dbatools/blob/master/dba... for an example.
    - c0wb0yc0d3r 9y ago
      Awesome, that is similar to what I do right now.
nthcolumn 9y ago
Agree - I find the thing incomprehensible without some sort of intellisense running (which I abhor I tell you abhor!) seems arcane and weird to me and much prefer c# but "WHY ARE ATTACKERS USING POWERSHELL?" - simply because its already there probably? And cmdlets are a bit like nmap scripts - if you can read lua you can probably spitball them together. I'm not sure that ps is amazingly more powerful - just all we before was .bat from hell and debug sadly gone now...
Scaevolus 9y ago
Sometimes it's better to write something in a more advanced language, but for small tasks it's hard to beat the overhead of a shell! There are crossover points (varying by person) where a scripting language is preferable to a shell, and where a strongly-typed language is preferable to a dynamically-typed language.
- throwaway7645 9y ago
  PowerShell is a scripting language though, but it can also be used as a shell. The syntax is more advanced now that it has classes...etc.
InclinedPlane 9y ago
I wish I could give out a prize for comments like this. "I tried to use X language casually for a few days and didn't like it, it must objectively suck!" PowerShell isn't 10x harder to use than C#, how do I know that? Because many people use PowerShell regularly in their day to day jobs, and do so quite successfully. Most people who actually use PowerShell don't complain about how hard it is. It is harder than C# to debug, probably more than twice as hard, actually. Does that make it impossible to program in? Hardly. There are tons of other languages that are roughly equally difficult to debug, especially many of the dynamic languages: PHP, Python, etc. People have been building things of tremendous value with hard to debug languages for ages. The fact that C# has such a good debugging story is great, but it's not the end-all be-all of a language. Also, PowerShell has some significantly advanced debugging tools compared to a lot of other dynamic languages.
- ams6110 9y ago
  Different strokes. Different people grasp concepts differently. I can say that every programming language that I grew to love, I liked almost immediately. The ones that make no sense from the get-go, I don't spend much time on.
  - JadeNB 9y ago
    > I can say that every programming language that I grew to love, I liked almost immediately. The ones that make no sense from the get-go, I don't spend much time on. Surely the second sentence is the reason for the first? If you don't give languages that make a bad first impression a second chance, then you have no idea whether you would have grown to love one of them. (Certainly you aren't obliged to find out, but to regard this as evidence that you wouldn't have liked them I think is reversing causality.)
drak0n1c 9y ago
He said "as a complete non-techie".
yks 9y ago
I started using F# scripts instead of PowerShell or compiled C#. Just got to copy Fsi.exe and a few other dlls onto the target machine for it to work.

chubot 9y ago

Do you have an example of that? I'm curious how PowerShell is better than other languages for this type of problem. Does it just have good built-in parallelism?

Numberwang 9y ago
You can see my entire thinking outlined in my reddit thread. https://www.reddit.com/r/PowerShell/comments/5f4r10/web_scraping_newb_question/ https://www.reddit.com/r/PowerShell/comments/5f4r10/web_scra... I miss-remembered the number of sited scraped but it's all the same. There is no parallelism (I really really am a complete non-techie) but actually in this case I didn't want to hammer away as the sites were all under the same domain and I imagine there might be trouble (which I why I also played it very safe and added the pause). I know there are better and smarter ways of doing things and I did further modifications and experiments after my thread, but in any case, I had a task and was able to quickly complete it in PowerShell starting from absolute 0.
joeyaiello 9y ago
Disclaimer: I'm a PM who works on PowerShell at Microsoft There's a bunch of 3rd-party modules out there that do a great job of offering parallelism[1][2][3], and we also support the notion of "PowerShell Jobs"[4] (which one or two of those third-party implementations actually build on to achieve what they're doing). However, we decided that strong parallelism support is important enough to build into the language, so we're mulling on a first-party design. If you're interested, we've got an RFC out where we're looking for feedback on the parallelism/concurrency design.[5] [1]: https://www.powershellgallery.com/packages/PSParallel/ https://www.powershellgallery.com/packages/PSParallel/ [2]: https://www.powershellgallery.com/packages/SplitPipeline https://www.powershellgallery.com/packages/SplitPipeline [3]: https://github.com/RamblingCookieMonster/Invoke-Parallel https://github.com/RamblingCookieMonster/Invoke-Parallel [4]: https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.core/about/about_jobs https://msdn.microsoft.com/en-us/powershell/reference/5.1/mi... [5]: https://github.com/PowerShell/PowerShell-RFC/issues/85 https://github.com/PowerShell/PowerShell-RFC/issues/85
- 9y ago

dkhenry 9y ago

PowerShell is a little bit more difficult then something like Python or a well equipped Bash shell, but the fact that you can do it shows how much progress it has made

IshKebab 9y ago
I would say nothing is much less intuitive than a Bash shell. Maybe the Git CLI. But Bash is spectacularly unintuitive. How do I rename files? `mv`? List files is `ls`? Why not `list`? What the hell does `2>&1` even do?! Have you ever looked at the escaping options of `ls`? How do I end a for look? `fi`? WTF kind of a weird joke is that? If you're thinking "but... it's all so obvious. What is this guy talking about", ask yourself how long ago you first typed a shell command. Can you even remember how hard it was to learn? For me it was something like 15 years and I actually can remember because it made such an impression on me how terrible a system it was. (That and X86Config if you remember that insanity.) Even though it was awful to learn, it feels totally easy and 'intuitive' to me now. But that's just because I use it so much. It's not intuitive. Don't fall into the old curmudgeon trap of thinking the thing that you find trivial through experience is actually good. /rant
- jrochkind1 9y ago
  Maybe it's intuitive compared to whatever else there was in the 70s when the bourne shell was invented? I dunno. I agree, bash is not very intuitive to the contemporary scripter _especially_ when you get into scripting.
- lottin 9y ago
  What were you using before? Compared to DOS the Unix shell actually seemed a very well designed system. There are a couple of things that are admittedly hard to grasp, redirection being one of them. But I have no problem with mv and ls. By the way, fi closes an if block. A for loop uses do and done.
  - richfnelson 9y ago
    In DOS you use `dir` to list files in a directory. You can also use `dir` to list files that match a string in a directory. `dir 1.png` would list all PNGs with a "1" in their name. You need a separate command with options and a flag to do that in bash. In DOS, it's less than a dozen characters, and it's far more intuitive than having to use `find`. Sure, `find` and `ls` might be more flexible, but definitely not more intuitive.

hackunomatter 9y ago

A judicious use of xargs, curl and grep would have done it in 1 line in Linux. I looked at your PowerShell code; that does look a bit complicated compared to what Linux offers.

Numberwang 9y ago
I'm sure you are right. I was just trying to convey the positive impression I got from what little time I spent with PowerShell and the great documentation it has. Especially the fact that I was able to accomplish what I set out to do in a very reasonable amount of time.
Arnavion 9y ago
You can do it in one line in PS too. $sites = @('https://www.google.com/', 'https://www.example.com/') $searchString = 'oogle' $sites | %{ if ((iwr $_).Content -like "*$searchString*") { "$_;OK" } else { "$_;NOT OK" } } > C:\temp\output.csv

shallot_router 9y ago

As a security analyst/engineer, PowerShell is both one of my favorite (for collecting information, forensics, administrating and protecting, etc.) and least favorite (because practically every day we're fending off malware using different PowerShell techniques we have to detect and mitigate, plus it's a favorite of APTs) tools.