-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Closed
Closed
Copy link
Labels
Breaking-Changebreaking change that may affect usersbreaking change that may affect usersIssue-BugIssue has been identified as a bug in the productIssue has been identified as a bug in the productResolution-FixedThe issue is fixed.The issue is fixed.WG-Enginecore PowerShell engine, interpreter, and runtimecore PowerShell engine, interpreter, and runtime
Description
Steps to reproduce
PS D:\> New-Item 7nExpected 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!).
mklement0
Metadata
Metadata
Assignees
Labels
Breaking-Changebreaking change that may affect usersbreaking change that may affect usersIssue-BugIssue has been identified as a bug in the productIssue has been identified as a bug in the productResolution-FixedThe issue is fixed.The issue is fixed.WG-Enginecore PowerShell engine, interpreter, and runtimecore PowerShell engine, interpreter, and runtime