Steps to reproduce
Expected behavior
(and current behavior in PS 6)
Directory: D:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 1/18/2020 1:24 PM 0 7n
Actual behavior
A file with an unexpected name is created.
Directory: D:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 1/18/2020 1:24 PM 0 7
Environment data
Name Value
---- -----
PSVersion 7.0.0-rc.2
PSEdition Core
GitCommitId 7.0.0-rc.2
OS Microsoft Windows 10.0.18363
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
When the other numeric types are used as an argument, PS wraps them inside a [psobject] if their numeric and string representations differ so that PS can extract the original string if needed later (e.g. if it's bound to a [string[]] parameter as with New-Item above.) Thus New-Item 7ul works as expected, but New-Item 7n does not.
I'm sorry but I don't know how/where this happens in the code though....
Mentioning @vexx32 because I believe they created the BigInt type-suffix support (thanks!).
Steps to reproduce
Expected behavior
(and current behavior in PS 6)
Actual behavior
A file with an unexpected name is created.
Environment data
When the other numeric types are used as an argument, PS wraps them inside a
[psobject]if their numeric and string representations differ so that PS can extract the original string if needed later (e.g. if it's bound to a[string[]]parameter as withNew-Itemabove.) ThusNew-Item 7ulworks as expected, butNew-Item 7ndoes not.I'm sorry but I don't know how/where this happens in the code though....
Mentioning @vexx32 because I believe they created the BigInt type-suffix support (thanks!).