Comment by PreInternet01 | Hacker News Reader

Comment by PreInternet01 | Hacker News Reader

Well, I don't, and I'm a Windows fanboy. So, why, exactly none of you ask:

1. The PowerShell separation of, what on *ix* systems is stdout and stderr, doesn't really work. Want to know whether your invocation of a PowerShell command worked? Well, it might be that the error stream has content, otherwise check the warning stream, otherwise check the regular output stream, and see if it contains an error-message-like-ish string

2. Continuing on this theme, just 'give me all the output, regardless of type/class, from this command' is just plain impossible. You want to see what this command would print on a terminal? Good luck with that!

3. Serializing PowerShell output to JSON (which, naively, you would assume would be sort-of reliable) generates heaps of PS*-specific junk. Just the common '|fl XXX' expression will trigger this

4. Even commands that appear to be successful, may in fact have failed. The Azure commandlets are especially guilty of this. Remove a load balancer NAT rule? Sure, we'll pretend to do that! Except, nothing happens, and you'll need a support ticket to actually modify your configuration

What do you mean with #3? A command like below runs perfectly fine with no PS* specific junk.

``` > Get-Process | Select -Last 5 Name,ProcessName,Company,Path | ConvertTo-Json [ { "Name": "winlogon", "ProcessName": "winlogon", "Company": null, "Path": null }, { "Name": "WmiPrvSE", "ProcessName": "WmiPrvSE", "Company": null, "Path": null }, { "Name": "WMIRegistrationService", "ProcessName": "WMIRegistrationService", "Company": null, "Path": null }, { "Name": "Zoom", "ProcessName": "Zoom", "Company": "Zoom Video Communications, Inc.", "Path": "C:\\Users\\user\\AppData\\Roaming\\Zoom\\bin\\Zoom.exe" }, { "Name": "Zoom", "ProcessName": "Zoom", "Company": "Zoom Video Communications, Inc.", "Path": "C:\\Users\\user\\AppData\\Roaming\\Zoom\\bin\\Zoom.exe" } ] ```

And when you say "Just the common '|fl XXX' expression will trigger this" does that mean you are doing this `<command> | fl X | ConvertTo-Json`? Because if so, that's why your getting all the PS specific junk.

IIRC HN really wants an indented paragraph for code blocks, your ``` did not go precisely to plan, I don't think - if you indent:

  ```
    foo
    bar
  ```

it'll be happier.

1. You check `$LastExitCode`, similar to `$?`. You can also catch exceptions when dealing with real Powershell commands.

2. Try piping your output through `| Format-List -Property *`. This isn't very discoverable really.

3. Try selecting the properties you want: `| select Name, ID, Etc`

4. This is the fault of the module developer, not Powershell. You can also write bad software in C.

`$?` works and is more reliable. Git notoriously gives non-zero exit codes for success conditions

1. Native PS is easy. Binary commands are no harder than on any other platform, but I find $? to be reliable. Now you know.

2. Pipe to Out-String. Now you know.

3. Format commands generate console-host-specific markup. You would never pipe through FL to json, that's a bizarre thing to do. You're complaining that the boot doesn't fit on your head. If you want to filter properties, use select or generate new objects in foreach.

4. Fair, but not a Powershell issue

The only point I would raise is that #1 isn't reliable on any system that has stdout/stderr. For most of the MS-created modules this is implemented correctly. You also have the ability to catch and throw exceptions... foreign to people who live in scripts but essential for people who have programming experience.

Yeah, lets take 4 random things and yell around it sux.

That's a remarkably insightful rebuttal. I sure see the errors of my way now. Except I'm not really sure whether these are in the Output, Error, Warning, Verbose or Debug stream, so...

It doesn't need insightful rebuttal :)

But ...

    1. *> is a thing
    2. see above, I agree that Start-Transcript could be better and include all
    3. Just provide your own massaged JSON
    4. Not a pwsh problem, problem in general. For example take a look at Invoke-Builds `exec` as one way to handle this

But really, 4 random things, and you don't like 2 decades of work. Awesome!

> 1. > is a thing

Silly how you need sh to do a very basic thing in PowerShell

What? Did you think this trough? Give it another try.

> 3. Just provide your own massaged JSON

or use -Depth parameter...

Reply on news.ycombinator.com