[Samon]

I write hundreds of lines of PowerShell every day, and quite like it as a language. Coming from a C# developer background, I initially struggled when I first started with PowerShell, but I believe this was mainly 1: the many quirks and issues with the early versions of PowerShell (this was back in PowerShell v1 days), and 2: that I was trying to use PowerShell as if it were C# (or a similarly 'structured' language).

Yes, the output from calling native commands within functions can be a little tricky, and something that annoyed me initially, but once you understand the concept of passing objects around, not strings, you quickly get used to either capturing the output into a variable ($BlahResult = .\blah.exe /foo bar /baz 2>&1), where you can then access the string output (stdout) and any ErrorRecord (stderr) lines, or as you suggested, piping to Out-Null if you don't actually need the output. If you're writing your own 'echo' type statements for debugging or information purposes, you learn to use Write-Verbose or Write-Debug instead of Write-Output (which is what happens by default).

The unwrapping example was something that got me initially, because I was used to defining a collection (array, List, whatever), populating it, and then returning that collection... and then having the calling code iterate over that collection. "The PowerShell way" is to not focus on the collection/array at all, but instead just let it take care of that and deal with the items themselves. If you pipe the output of a function to Foreach-Object, it will work correctly - if it's a single object returned, that's what will be $_ in the loop, if it's multiple, they will all be passed in one-by-one as $_... if you actually want to access the array itself (for example to count the number of items), then you can enforce the array type by wrapping it in an additional array (i.e. @($Users).Count).

[kabdib]

If you stay in PowerShell I guess that's okay. But I interop with Python and other things a fair amount, via JSON, and have had to write wrappers and guards against the unwrapping nonsense.

But "... quickly get used to" is more readily translated as "Spent an afternoon debugging, found the reason, did a forehead plant on the keyboard, then tried to remember on every invocation, so as not to get burned again."

Python, LISP, Smalltalk and a host of other languages made much better decisions in similar areas.

[stephengillie]

Powershell can convert JSON objects to .NET objects with ConvertFrom-Json. And it outputs decent JSON by piping objects to ConvertTo-Json. I think few people know about these cmdlets, but combined with Invoke-WebRequest, they offer access to any JSON API.

Since .NET objects can't be copied from one session and pasted through RDP into another, I'll often take an array or other object, and pipe it through ConvertTo-Json into clip.exe, which throws the JSON onto my clipboard. In the RDP session, I'll pipe Get-Clipboard into ConvertFrom-Json, all written into a variable.

Piping ( | ) sends objects from one cmdlet to another. Many cmdlets and functions have a preset parameter for pipeline input, and it's easy to specify this when making your own functions. Foreach-Object ( % ) can have cmdlets act against each item in the pipeline, with $_ being the "this" character. Just remember to wrap them in curly brackets, as this marks them as as the script block being invoked.

Additionally, Powershell can interoperate with CSV just as easily, with ConvertFrom-CSV and ConvertTo-CSV.

Want a simple API? Here's a one-liner - just host the output with IIS:

While ($true) {Get-Process | ConvertTo-Json > C:\www\ApiFile.html; sleep 60}

For a more interactive API, the .NET HTTPListener class can easily be called and built upon.

My favorite part of the language is the type system, where you just put the .NET type in square brackets before the variable. [string]$myString = "Hello World"

[kabdib]

Here's another absolutely classis interaction with PowerShell. Let's make a list of strings; I'm partly interested in what CSV conversion does to values that already have commas.

    PS> $x = @('a', 'b', 'c', 'd,xx', 'e')

    PS> $x
    a
    b
    c
    d,xx
    e

Okay, that's great. Now:

    PS> $x | ConvertTo-json
    [
        "a",
        "b",
        "c",
        "d,xx",
        "e"
    ]

Hey, conversion to JSON works! But let's try the CSV conversion:

    PS > $x | ConvertTo-Csv
    #TYPE System.String
    "Length"
    "1"
    "1"
    "1"
    "4"
    "1"

... and I think I just died a little inside. I didn't even get to answer the original question I had about escaping separators. I have no earthly idea why PowerShell decided to spew the lengths of the elements rather than the values, or what the hell the other gorp in the output is.

The official documentation is not much help. I could go do some research on StackOverflow and so forth, but . . . I've lost the will to live. For this little exercise I've reached the point of uncaring.

This is basically my everyday interaction with PowerShell; try out something new, have it fail in a way that this LISP / Python / C++ / etc. veteran would never expect, and spend 20 minutes or maybe a whole bloody day researching why, or working around the behavior with other tools. I could become an expert in PowerShell, but I'm not interested, I just want things to work in reasonable ways. I've got shit to do. [I'm writing this HN post because in ten minutes I get to dive into some more PowerShell]

PowerShell has repeatedly failed the "reasonable expectation" test. I can't depend on it to be a lightweight and useful tool. Instead, every time I use it I can expect to spend 60 percent of my time working around capricious nonsense, dredging through postings by other people who have thankfully preceded me.

[deburo]

It's about knowing what the function expects to receive.

What you got seems unexpected initially, but as you read the doc on this function (which took me a good 20 secs) you may think it is indeed well conceived, and realize that it was weird to expect passing an array of strings to it and expect it to work.. I don't even know what it should've done.

Should it have given you a single line of comma separated values? But then what should you give to the function to have multiple lines of csv? An array of array of strings?

[latkin]

"$arrayOfObjects | ConvertTo-Csv" will create one row per object in the array, with a column for each public field of the object. That's exactly what happened, and it seems like a reasonable behavior to me.

Do you have an alternative? Maybe for the edge case where the contents of the CSV is a list of primitives, it should give you a "Value" column? Or did you expect that, given an array of stuff, the best approach is to encode the whole array in a single CSV row?