Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Unify cmdlets with parameter 'Encoding' to be of type System.Text.Encoding #5080
This unifies file encoding across the inbox cmdlets to be UTF-8 without a BOM for all platforms. This is a breaking change as cmdlets on windows have a number of different encodings. This supports better interoperability with tradition Linux shells as we are using the same encoding.
Validate that files are created with UTF-8 encoding without BOM
Breaking Change The
requested review from
Oct 10, 2017
I think this class should be in its own CS file; it's not a path utility and discoverability is problematic.
In fact, I think this and the associated ArgumentToEncodingTransformationAttribute should be moved into an encoding file.
A message from the COSP (Crying Over Spilt Milk) department:
This results in an awkward user experience, because users will expect incompatible parameters to be in different parameter sets, with attempts to combine them resulting in an error, not a warning.
A step backward in usability, and a breaking change to boot - and no gain that I can discern.
I also agree with @iSazonov that forgoing compatibility with the legacy encoding behavior on Windows altogether will dismay many Windows users, especially those whose "ANSI" / OEM code pages aren't based on the Latin alphabet.
If the idea is to focus on the Unix crowd first, I see trouble as well: broken quoting, broken CLI, broken globbing, lack of
referenced this pull request
Oct 19, 2017
@mklement one of the considerations the committee acknowledged is the complexity of using multiple parametersets to make parameters mutually exclusive so we were ok with using a warning as a simplification until we can revisit the recalled RFC on making it easier to both define as well as understand mutually exclusive parameters
I'm now looking at
FileSystemProvider.cs, but want to share my feedback early.
The change from property to field for some of the Encoding parameters needs to be reviewed for null references. MatchString.cs is one case where the parameter is a field, it is not mandatory, not marked as ValidateNotNull and is passed to an underlying StreamReader unchecked.