Powershell: Format-Hex should support all primitive types (including enums) and arrays of these types - instead of this random assortment.

[Francisco-Gamino]

Steps to reproduce

Format-Hex should support all primitive types (including enums) and arrays of these types - instead of this random assortment.

Take a look at the prototype https://gist.github.com/lzybkr/9940b63c8301c31316bdb3ec6305536f written by @lzybkr.

Expected behavior

Actual behavior

Environment data

> $PSVersionTable

[iSazonov]

@SteveL-MSFT The enhancement was made. Can we close or there is anything that we should add?

[SteveL-MSFT]

@iSazonov it doesn't appear that the enhancements to format-hex addresses this issue. Based on the gist sample, I think the expectation is that this will work:

[System.Net.HttpStatusCode]::OK | format-hex

Which still fails.

[iSazonov]

@SteveL-MSFT Thanks! I realized the idea. Will look the code.

[iSazonov]

I wonder why Maria did not use Jason code? Was there some discussion internally?

[SteveL-MSFT]

@iSazonov good question, @MiaRomero reports to a different manager, so I don't know what discussions took place or didn't

[MiaRomero]

@SteveL-MSFT and @iSazonov this was part of my internship project and unfortunately I didn't have time to implement what Jason had recommended. I wasn't aware of his code until the PR ( #3320) was almost complete and then my internship was over :(

[SteveL-MSFT]

@MiaRomero no worries, we just didn't have the context!

[iSazonov]

Thanks for clarify. Will continue to look how to adopt the Jason's code.

[vexx32]

For anyone looking at this issue, I would also like to point out that the behaviour and handling of piped input is _weird_.

For example, if you pipe a series of bytes into it, I would expect a display like this, which I _do_ get if I supply the file path directly:

           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   EF BB BF 74 65 73 74 0D 0A                       test..

Instead, if I pull the file bytes first with [System.IO.File]::ReadAllBytes() and pipe to Format-Hex, we get this:

           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   EF                                               ï


           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   BB                                               »


           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   BF                                               ¿


           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   74                                               t


           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   65                                               e


           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   73                                               s


           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   74                                               t


           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   0D                                               .


           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   0A                                               .

Which is a bit tricky to read! 😄

[iSazonov]

It is expected because you pipe an _array_. You could read as string and then pipe the string.

[vexx32]

If you read as string, then you miss the BOM, which may well be what you care about.

Most cmdlets handle a piped array and a directly input array the name. This cmdlet currently does not. If you pass an array directly it works; the handling for piped input is simply at odds with the behaviour for most other cmdlets'.

[vexx32]

I think I address basically everything in #8596

Many thanks @lzybkr for that concept code that is _far_ cleverer than I could figure out myself without at least a week's work, and thanks @Francisco-Gamino for the link!

@SteveL-MSFT just because you brought that one up 😉

If there are any improvements I can make further, let me know in the PR, I'll be happy to tackle it. 😄

[iSazonov]

@vexx32 There is #8191

[msftrncs]

@iSazonov, is the issue with piping arrays supposed to be fixed? I just noticed it in 6.2, then found this old thread.

[msftrncs]

Samples:

[byte[]](1,2,3,4,5,6,7,8,9,0) | format-hex
format-hex -inputobject ([byte[]](1,2,3,4,5,6,7,8,9,0))

[rkeithhill]

Also, it would be nice to have a switch param like -Bare or -SuppressHeaders so such Format-Hex -Inp 65535 -SuppressHeaders would output simply 0000FFFF. And for @msftrncs case:

[byte[]](1,2,3,4,5,6,7,8,9,10) | format-hex

the output would be vastly simplified to just:

01
...
09
0A

[vexx32]

@msftrncs I actually had the same gripe and submitted a PR to attempt to solve that issue more elegantly. See #8674 😄

Seems to be a bit of contention as to whether it's necessary for whatever reason, but personally I think it's a pretty significant improvement in terms of utility. 🙂

@rkeithhill would -ValueOnly make sense there? It definitely would create a much more interesting and versatile output, being a very direct method of converting basically anything to hex format.

[iSazonov]

@rkeithhill @vexx32 Please open new Issue for the suggestion.

[vexx32]

@iSazonov see #9403