Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions Archive/Rejected/RFC0005-Typed-Interprocess-communication.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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.
Expand All @@ -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.
Expand Down Expand Up @@ -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
Expand All @@ -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

Expand Down
8 changes: 4 additions & 4 deletions Archive/Rejected/RFC0015-PowerShell-StartupConfig.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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
Expand Down Expand Up @@ -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:

Expand Down Expand Up @@ -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
Expand Down
6 changes: 3 additions & 3 deletions Draft-Accepted/RFC0065-Install-PowerShell.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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.
Expand Down
4 changes: 2 additions & 2 deletions Final/RFC0045-Ternary-Operator.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down Expand Up @@ -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,
Expand Down