From 51c751e13145c6caab9c79cd8f4e6f15f93c60c6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9on=20Avic=20Simmons?= Date: Sat, 19 Sep 2026 05:05:48 -0400 Subject: [PATCH] docs: fix 16 typos in convention/grammar/typo --- .../RFC0005-Typed-Interprocess-communication.md | 14 +++++++------- .../Rejected/RFC0015-PowerShell-StartupConfig.md | 8 ++++---- Draft-Accepted/RFC0065-Install-PowerShell.md | 6 +++--- Final/RFC0045-Ternary-Operator.md | 4 ++-- 4 files changed, 16 insertions(+), 16 deletions(-) diff --git a/Archive/Rejected/RFC0005-Typed-Interprocess-communication.md b/Archive/Rejected/RFC0005-Typed-Interprocess-communication.md index 8e1ef3d17..cc011cca9 100644 --- a/Archive/Rejected/RFC0005-Typed-Interprocess-communication.md +++ b/Archive/Rejected/RFC0005-Typed-Interprocess-communication.md @@ -8,11 +8,11 @@ Area: Implementing typed IPC. # Typed Interprocess communication -Currently PowerShell does not have an efficient means of IPC, as the architecture [of unstructured/semi-structured text-based systems] itself forces extraneous computation, making long-chains highly inneffient and often error-prone. +Currently PowerShell does not have an efficient means of IPC, as the architecture [of unstructured/semi-structured text-based systems] itself forces extraneous computation, making long-chains highly inefficient and often error-prone. ## Motivation -As we know from prior experience languages like PHP the usage of text as an interface is inherently error-prone (which is often a key in security-vulnerabilities), even moreso when the implementation of the producer are not available to the consumer thus forcing an *ad hock* reverse-engineered solution. +As we know from prior experience languages like PHP the usage of text as an interface is inherently error-prone (which is often a key in security-vulnerabilities), even moreso when the implementation of the producer are not available to the consumer thus forcing an *ad hoc* reverse-engineered solution. A solution to this problem could be achieved through the use of a “typed stream” rather than untyped text. Another consideration is if the data passes through several processes/transforms and has to be serialized/deserialized [from text] a lot of unnecessary processing is being forced into the process — while this may be negligible in many cases it definitely adds up when dealing with large amounts of data and/or long chains of processes where the deserialize/serialize must be used. @@ -35,7 +35,7 @@ This RFC proposes the following: 0. Interface — Tree containing types for various external systems. * e.g. a type for TCP-connections or other items which are commonly implemented as Integers but not technically integers; or things like “Little-endian, 16-bit value, unsigned” and “Little-endian, 16-bit value, signed”. 0. User — Defined for user-added types. - * This could also be [or contain] an “undefined” tree where anything below is system-dependant. While that would defeat the much of the usage of the OID-system, it would allow a sort of “type-registry” for the user’s system. (Not recommended, but a possibility nonetheless.) + * This could also be [or contain] an “undefined” tree where anything below is system-dependant. While that would defeat much of the usage of the OID-system, it would allow a sort of “type-registry” for the user’s system. (Not recommended, but a possibility nonetheless.) 0. The system should provide for efficient transmission and be reliable (complete serialize/deserialize roundtrip). * ASN.1 has the advantage that proper, unambiguous message-passing (in our case typed information) is efficient. 0. The system should provide for error-checked values. @@ -52,9 +52,9 @@ Invariably someone will suggest something like JSON as a solution to this proble 0. JSON does not provide a means to check/enforce constraints, meaning that all clients will have to manually implement the check. 0. JSON does not provide a means to check/enforce a structure, meaning that all clients will have to manually implement the check. 0. Because of #2 JSON is unsuitable for transmitting records ("structs"), because of #1 JSON is unsuitable for transmitting objects (essentially stateful records). -0. Because of #3 JSON is unsuitable for seralizing/deserializing complex/compound types such as are used in .NET. +0. Because of #3 JSON is unsuitable for serializing/deserializing complex/compound types such as are used in .NET. -Viable alternitives would include: +Viable alternatives would include: * The Wulf, Lamb, Nestor [Interface Description Language](http://repository.cmu.edu/compsci/2412/); see also [Snodgrass’s book](https://www.amazon.com/Interface-Description-Language-Definition-Principles/dp/0716781980) ISBN 0716781980. * Possibly w/ updated syntax to be more in-line with Ada-2012/SPARK-2014; see example #1 below. @@ -89,7 +89,7 @@ Example 1: ) ); - -- Tax_ID: A string guarenteed to be an SSN or EIN. + -- Tax_ID: A string guaranteed to be an SSN or EIN. -- SSN (###-##-####) -- EIN (##-#######) Subtype Tax_ID is ID_String @@ -114,7 +114,7 @@ Hemant Mahawar: Reject ### Majority Decision -Commmittee agrees that this RFC does not provide sufficient details to move forward with an implementation. PowerShell already supports IPC within PSRP (PowerShell Remoting Protocol). +Committee agrees that this RFC does not provide sufficient details to move forward with an implementation. PowerShell already supports IPC within PSRP (PowerShell Remoting Protocol). ### Minority Decision diff --git a/Archive/Rejected/RFC0015-PowerShell-StartupConfig.md b/Archive/Rejected/RFC0015-PowerShell-StartupConfig.md index e26931a87..bae838485 100644 --- a/Archive/Rejected/RFC0015-PowerShell-StartupConfig.md +++ b/Archive/Rejected/RFC0015-PowerShell-StartupConfig.md @@ -44,7 +44,7 @@ Additional keys and subkeys may be added as needed. Keys which are not supported shall generate a _warning_ and be ignored. The configuration file in $PSHOME shall be applicable only to the PowerShell executable found therein. -The configuration file in $HOME (PowerShell._version_.Config.psd) shall be applicable to only to the matching version of PowerShell Core. +The configuration file in $HOME (PowerShell._version_.Config.psd) shall be applicable only to the matching version of PowerShell Core. Additionally, the parameter `-ConfigurationFile` shall be present in the PowerShell executable, which takes an array of strings which represent paths to config files. When the `-ConfigurationFile` parameter is present, those files only will be read for configuration data. @@ -55,7 +55,7 @@ The config file should have a published schema to aid in file creation. * Tools to ease the creation/alteration/removal of settings should be created at a future date. ### Additional Optional Work -We should have a mechanism for creating default config files, we could easily modify existing code for New-PSSessionConfiguraitonFile to do this, however this is not a requirement. +We should have a mechanism for creating default config files, we could easily modify existing code for New-PSSessionConfigurationFile to do this, however this is not a requirement. ### Sample configuration file ```powershell @@ -108,7 +108,7 @@ And $HOME configuration file defines it as: } } ``` -The the resultant configuration will be as defined by the file in $HOME. +The resultant configuration will be as defined by the file in $HOME. However, if the configuration does not overlap then the settings will not be overridden: @@ -154,7 +154,7 @@ The current proposal provides for those settings to be unalterable by a user whi ### Datafile Formats The format for the datafile could take many forms; XML, json, Linux Config, .yml, or .ini. I chose PowerShell Data format assuming that anyone that is configuring PowerShell is familiar with PowerShell constructs, and code is available to convert a PSD1 file to an object before the engine is started. -Also, PSD1 files may conin comments, which may be very helpful in describing the settings. +Also, PSD1 files may contain comments, which may be very helpful in describing the settings. The config file location is somewhat forced due to PowerShell's side-by-side requirements, so a global location (.e.g., `/etc/`) would greatly complicate the configuration file to cover multiple versions. ## PowerShell Committee Decision diff --git a/Draft-Accepted/RFC0065-Install-PowerShell.md b/Draft-Accepted/RFC0065-Install-PowerShell.md index 915aac346..855baffc9 100644 --- a/Draft-Accepted/RFC0065-Install-PowerShell.md +++ b/Draft-Accepted/RFC0065-Install-PowerShell.md @@ -79,7 +79,7 @@ Goals: - By default, download and install the latest LTS release to the users CurrentUser Scope - CurrentUser - default installation scope location - - AllUsers - Administrative users may explicit select this scope. AllUsers requires administrative + - AllUsers - Administrative users may explicitly select this scope. AllUsers requires administrative elevation and performs a silent install using the MSI defaults. - Allow advanced users to specify channel Stable/Preview/LTS - Tool will not partially install and leave any existing PowerShell in a non-functioning state. @@ -108,8 +108,8 @@ privilege, they can choose to install the msi package silently to the scope of A - The preview package install location - $env:LOCALAPPDATA\Local\Programs\PowerShell-Preview - If path exists, Provide an error "PowerShell 7 Preview is already installed, use --clobber to overwrite existing installation" -- Detect if Powershell is in use in the target folder and provide error "PowerShell is currently in - use. Please close all Powershell instances and run the command from Start->Run or cmd.exe." +- Detect if PowerShell is in use in the target folder and provide error "PowerShell is currently in + use. Please close all PowerShell instances and run the command from Start->Run or cmd.exe." - The installer should update the `$ENV:PATH` and Users PATH in the registry. - The installer should enable Microsoft Updates for scope AllUsers. - The command should show a progress bar during the download and installation of PowerShell 7. diff --git a/Final/RFC0045-Ternary-Operator.md b/Final/RFC0045-Ternary-Operator.md index 8f25bb354..30f5a52a1 100644 --- a/Final/RFC0045-Ternary-Operator.md +++ b/Final/RFC0045-Ternary-Operator.md @@ -11,7 +11,7 @@ Plan to implement: Yes, PS7 # Add Ternary Operator to PowerShell Language -The ternary operator is one of the highly demanded enhancement to PowerShell language. +The ternary operator is one of the highly demanded enhancements to PowerShell language. It received 46 up-votes in the issue [Suggestion: implement ternary conditionals](https://github.com/PowerShell/PowerShell/issues/3239) as of the writing of this RFC. The [prototype draft pull request](https://github.com/PowerShell/PowerShell/pull/10161) for this feature has also received a lot of attention and discussions. @@ -109,7 +109,7 @@ Obvious examples are the `VariableAnalysis` and `Compiler` as you have to update The not-so-obvious ones include `ConstantValueVisitor`, `SafeValueVisitor`, `TypeInferenceVisitor` and more. Take the `TypeInferenceVisitor` as an instance, failing to update it may cause tab completion issues that are hard to catch. -It's worth to discuss the `InternalVisit` implemention of the new AST type a bit. +It's worth to discuss the `InternalVisit` implementation of the new AST type a bit. Many `Find*Visitor` types depend on this method to search through an AST tree, and almost all of them derive from `AstVisitor` instead of `AstVisitor2` because currently the AST types covered in `AstVisitor2` all have their own special scopes,