Updates from: 03/13/2021 04:13:03
Service Microsoft Docs article Related commit history on GitHub Change details
Microsoft.PowerShell.Core About Arrays (5.1) https://github.com/MicrosoftDocs/PowerShell-Docs/commits/staging/reference/5.1/Microsoft.PowerShell.Core/About/about_Arrays.md
---
-description: Describes arrays, which are data structures designed to store collections of items.
-keywords: powershell,cmdlet
+description: Describes arrays, which are data structures designed to store collections of items.
Locale: en-US Last updated 08/26/2020 online version: https://docs.microsoft.com/powershell/module/microsoft.powershell.core/about/about_arrays?view=powershell-5.1&WT.mc_id=ps-gethelp
$a.Length
Returns the number of dimensions in the array. Most arrays in PowerShell have one dimension, only. Even when you think you are building a multidimensional
-array; like the following example:
+array like the following example:
```powershell $a = @(
$a = @(
@(Get-Process) )
-[int]$r = $a.Rank
-"`$a rank: $r"
+"`$a rank: $($a.Rank)"
+"`$a length: $($a.Length)"
+"`$a length: $($a.Length)"
+"Process `$a[2][1]: $($a[2][1].ProcessName)"
```
+In this example, you are creating a single-dimensional array that contains
+other arrays. This is also known as a _jagged array_. The **Rank** property
+proved that this is single-dimensional. To access items in a jagged array, the
+indexes must be in separate brackets (`[]`).
+ ```Output $a rank: 1
+$a length: 3
+$a[2] length: 348
+Process $a[2][1]: AcroRd32
```
-The following example shows how to create a truly multidimensional array using
-the .Net Framework.
+Multidimensional arrays are stored in
+[row-major order](https://wikipedia.org/wiki/Row-_and_column-major_order). The following example
+shows how to create a truly multidimensional array.
```powershell
-[int[,]]$rank2 = [int[,]]::new(5,5)
+[string[,]]$rank2 = [string[,]]::New(3,2)
$rank2.rank
+$rank2.Length
+$rank2[0,0] = 'a'
+$rank2[0,1] = 'b'
+$rank2[1,0] = 'c'
+$rank2[1,1] = 'd'
+$rank2[2,0] = 'e'
+$rank2[2,1] = 'f'
+$rank2[1,1]
``` ```Output 2
+6
+d
+```
+
+To access items in a multidimensional array, separate the indexes using a comma
+(`,`) within a single set of brackets (`[]`).
+
+Some operations on a multidimensional array, such as replication and
+concatenation, require that array to be flattened. Flattening turns the array
+into a 1-dimensional array of unconstrained type. The resulting array takes on
+all the elements in row-major order. Consider the following example:
+
+```powershell
+$a = "red",$true
+$b = (New-Object 'int[,]' 2,2)
+$b[0,0] = 10
+$b[0,1] = 20
+$b[1,0] = 30
+$b[1,1] = 40
+$c = $a + $b
+$a.GetType().Name
+$b.GetType().Name
+$c.GetType().Name
+$c
+```
+
+The output shows that `$c` is a 1-dimensional array containing the items from
+`$a` and `$b` in row-major order.
+
+```output
+Object[]
+Int32[,]
+Object[]
+red
+True
+10
+20
+30
+40
``` ## Methods of arrays
Microsoft.PowerShell.Core About Arrays (7.0) https://github.com/MicrosoftDocs/PowerShell-Docs/commits/staging/reference/7.0/Microsoft.PowerShell.Core/About/about_Arrays.md
---
-description: Describes arrays, which are data structures designed to store collections of items.
-keywords: powershell,cmdlet
+description: Describes arrays, which are data structures designed to store collections of items.
Locale: en-US Last updated 08/26/2020 online version: https://docs.microsoft.com/powershell/module/microsoft.powershell.core/about/about_arrays?view=powershell-7&WT.mc_id=ps-gethelp
$a.Length
Returns the number of dimensions in the array. Most arrays in PowerShell have one dimension, only. Even when you think you are building a multidimensional
-array; like the following example:
+array like the following example:
```powershell $a = @(
$a = @(
@(Get-Process) )
-[int]$r = $a.Rank
-"`$a rank: $r"
+"`$a rank: $($a.Rank)"
+"`$a length: $($a.Length)"
+"`$a length: $($a.Length)"
+"Process `$a[2][1]: $($a[2][1].ProcessName)"
```
+In this example, you are creating a single-dimensional array that contains
+other arrays. This is also known as a _jagged array_. The **Rank** property
+proved that this is single-dimensional. To access items in a jagged array, the
+indexes must be in separate brackets (`[]`).
+ ```Output $a rank: 1
+$a length: 3
+$a[2] length: 348
+Process $a[2][1]: AcroRd32
```
-The following example shows how to create a truly multidimensional array using
-the .Net Framework.
+Multidimensional arrays are stored in
+[row-major order](https://wikipedia.org/wiki/Row-_and_column-major_order). The following example
+shows how to create a truly multidimensional array.
```powershell
-[int[,]]$rank2 = [int[,]]::new(5,5)
+[string[,]]$rank2 = [string[,]]::New(3,2)
$rank2.rank
+$rank2.Length
+$rank2[0,0] = 'a'
+$rank2[0,1] = 'b'
+$rank2[1,0] = 'c'
+$rank2[1,1] = 'd'
+$rank2[2,0] = 'e'
+$rank2[2,1] = 'f'
+$rank2[1,1]
``` ```Output 2
+6
+d
+```
+
+To access items in a multidimensional array, separate the indexes using a comma
+(`,`) within a single set of brackets (`[]`).
+
+Some operations on a multidimensional array, such as replication and
+concatenation, require that array to be flattened. Flattening turns the array
+into a 1-dimensional array of unconstrained type. The resulting array takes on
+all the elements in row-major order. Consider the following example:
+
+```powershell
+$a = "red",$true
+$b = (New-Object 'int[,]' 2,2)
+$b[0,0] = 10
+$b[0,1] = 20
+$b[1,0] = 30
+$b[1,1] = 40
+$c = $a + $b
+$a.GetType().Name
+$b.GetType().Name
+$c.GetType().Name
+$c
+```
+
+The output shows that `$c` is a 1-dimensional array containing the items from
+`$a` and `$b` in row-major order.
+
+```output
+Object[]
+Int32[,]
+Object[]
+red
+True
+10
+20
+30
+40
``` ## Methods of arrays
Microsoft.PowerShell.Core About Powershell Config (7.0) https://github.com/MicrosoftDocs/PowerShell-Docs/commits/staging/reference/7.0/Microsoft.PowerShell.Core/About/about_PowerShell_Config.md
---
-description: Configuration files for PowerShell Core, replacing Registry configuration.
-keywords: powershell
+description: Configuration files for PowerShell, replacing Registry configuration.
Locale: en-US Previously updated : 11/02/2018 Last updated : 03/12/2021 online version: https://docs.microsoft.com/powershell/module/microsoft.powershell.core/about/about_powershell_config?view=powershell-7&WT.mc_id=ps-gethelp schema: 2.0.0 Title: about_PowerShell_Config
Configuration files for PowerShell Core, replacing Registry configuration.
The `powershell.config.json` file contains configuration settings for PowerShell Core. PowerShell loads this configuration at startup. The settings can also be modified at runtime. Previously, these settings were stored in the
-Windows Registry for PowerShell, but are now contained in a file to
-enable configuration on macOS and Linux.
+Windows Registry for PowerShell, but are now contained in a file to enable
+configuration on macOS and Linux.
> [!WARNING]
-> If the `powershell.config.json` file contains invalid JSON
-> PowerShell cannot start an interactive session.
-> If this occurs, you must fix the configuration file.
-
-> [!NOTE]
-> Unrecognized keys or invalid values in the configuration file
-> will be silently ignored.
+> Unrecognized keys or invalid values in the configuration file are silently
+> ignored. If the `powershell.config.json` file contains invalid JSON,
+> PowerShell cannot start an interactive session. If this occurs, you must
+> fix the configuration file.
### AllUsers (shared) configuration
configuration for all PowerShell Core sessions running from that PowerShell
Core installation. > [!NOTE]
-> The `$PSHOME` location is defined as
-> the same directory as the executing System.Management.Automation.dll
-> assembly. This applies to hosted PowerShell SDK instances as well.
+> The `$PSHOME` location is defined as the same directory as the executing
+> System.Management.Automation.dll assembly. This applies to hosted PowerShell
+> SDK instances as well.
### CurrentUser (per-user) configurations
For CurrentUser configurations, this sets the **CurrentUser** execution policy.
Where: -- `<shell-id>` refers to the ID of the current PowerShell host.
- For normal PowerShell Core, this is `Microsoft.PowerShell`.
- In any PowerShell session, you can discover it with `$ShellId`.
+- `<shell-id>` refers to the ID of the current PowerShell host. For normal
+ PowerShell Core, this is `Microsoft.PowerShell`. In any PowerShell session,
+ you can discover it with `$ShellId`.
- `<execution-policy>` refers to a valid execution policy name. The following example sets the execution policy of PowerShell to `RemoteSigned`.
In Windows, the equivalent registry keys can be found in
### PSModulePath
-Overrides a PSModulePath component for this PowerShell session. If the
-configuration is for the current user, sets the CurrentUser module path. If
-the configuration is for all users, sets the AllUser module path.
+Overrides the `PSModulePath` settings for this PowerShell session. If the
+configuration is for the current user, sets the **CurrentUser** module path. If
+the configuration is for all users, sets the **AllUsers** module path.
> [!WARNING]
-> Configuring an AllUsers or CurrentUser module path here
-> will not change the scoped installation location for PowerShellGet modules like [Install-Module](/powershell/module/powershellget/install-module).
-> These cmdlets always use the *default* module paths.
+> Configuring an **AllUsers** or **CurrentUser** module path here does not
+> change the scoped installation location for PowerShellGet cmdlets like
+> [Install-Module](/powershell/module/powershellget/install-module). These
+> cmdlets always use the _default_ module paths.
-If no value is set, the default value for the respective module path component
-will be used. See
-[about_Modules](./about_Modules.md#module-and-dsc-resource-locations-and-psmodulepath)
-for more details on these defaults.
+If no value is set, PowerShell uses the default value for the respective module
+path setting. For more information about these defaults, see
+[about_Modules](./about_Modules.md#module-and-dsc-resource-locations-and-psmodulepath).
This setting allows environment variables to be used by embedding them between `%` characters, like `"%HOME%\Documents\PowerShell\Modules"`, in the same way
-as CMD allows. This syntax also applies on Linux and macOS. See below for
+that CMD allows. This syntax also applies on Linux and macOS. See below for
examples. ```Schema
Where:
configurations, this is the AllUsers shared module directory. For current user configurations, this is CurrentUser module directory.
-This example shows a PSModulePath configuration for a Windows environment:
+This example shows a `PSModulePath` configuration for a Windows environment:
```json {
This example shows a PSModulePath configuration for a Windows environment:
} ```
-This example shows a PSModulePath configuration for a macOS or Linux
+This example shows a `PSModulePath` configuration for a macOS or Linux
environment: ```json
environment:
} ```
-This example shows embedding an environment variable in a PSModulePath
+This example shows embedding an environment variable in a `PSModulePath`
configuration. Note that using the `HOME` environment variable and the `/` directory separator, this will work on Windows, macOS and Linux.
directory separator, this will work on Windows, macOS and Linux.
} ```
-This example shows embedding an environment variable in a PSModulePath
+This example shows embedding an environment variable in a `PSModulePath`
configuration that will only work on macOS and Linux: ```json
configuration that will only work on macOS and Linux:
``` > [!NOTE]
-> PowerShell variables cannot be embedded in PSModulePath configurations.
-> PSModulePath configurations on Linux and macOS are case-sensitive. A
-> PSModulePath configuration must use valid directory separators for the
+> PowerShell variables cannot be embedded in `PSModulePath` configurations.
+> `PSModulePath` configurations on Linux and macOS are case-sensitive. A
+> `PSModulePath` configuration must use valid directory separators for the
> platform. On macOS and Linux, this means `/`. On Windows, both `/` and `\` > will work. ### ExperimentalFeatures
-The names of the experimental features to enable in PowerShell.
-By default, no experimental features are enabled.
-The default value is an empty array.
+The names of the experimental features to enable in PowerShell. By default, no
+experimental features are enabled. The default value is an empty array.
```Schema "ExperimentalFeatures": ["<experimental-feature-name>", ...]
Where:
- `<experimental-feature-name>` is the name of an experimental feature to enable.
-The following example enables the **PSImplicitRemoting**
-and **PSUseAbbreviationExpansion** experimental features
-when PowerShell starts up.
+The following example enables the **PSImplicitRemoting** and
+**PSUseAbbreviationExpansion** experimental features when PowerShell starts up.
```json {
when PowerShell starts up.
} ```
-For more information on experimental features, see [PowerShell RFC 29][RFC0029].
+For more information on experimental features, see
+[Using experimental features](/powershell/scripting/learn/experimental-features).
## Non-Windows logging configuration
Where:
> You may want to have different **LogIdentity** values for each different > instance of PowerShell you have installed.
-In this example, we are configuring the **LogIdentity** for a preview
-release of PowerShell.
+In this example, we are configuring the **LogIdentity** for a preview release
+of PowerShell.
```json {
Where:
- ManagedPlugin - WSMan plugin > [!NOTE]
-> It is generally advised to leave this value unset
-> unless you are trying to diagnose a specific behavior
-> in a known part of PowerShell.
-> Changing this value only decreases the amount of information logged.
+> It is generally advised to leave this value unset unless you are trying to
+> diagnose a specific behavior in a known part of PowerShell. Changing this
+> value only decreases the amount of information logged.
This example limits the logging to runspace operations, pipeline logic, and cmdlet use. All other logging will be omitted.
This configuration sets a number of options that only work in macOS or Linux:
[About Execution Policies](./about_Execution_Policies.md) [About Automatic Variables](./about_Automatic_Variables.md)-
-[RFC0029]: https://github.com/PowerShell/PowerShell-RFC/blob/master/5-Final/RFC0029-Support-Experimental-Features.md
Microsoft.PowerShell.Core About Arrays (7.1) https://github.com/MicrosoftDocs/PowerShell-Docs/commits/staging/reference/7.1/Microsoft.PowerShell.Core/About/about_Arrays.md
---
-description: Describes arrays, which are data structures designed to store collections of items.
-keywords: powershell,cmdlet
+description: Describes arrays, which are data structures designed to store collections of items.
Locale: en-US Last updated 08/26/2020 online version: https://docs.microsoft.com/powershell/module/microsoft.powershell.core/about/about_arrays?view=powershell-7.1&WT.mc_id=ps-gethelp
$a.Length
Returns the number of dimensions in the array. Most arrays in PowerShell have one dimension, only. Even when you think you are building a multidimensional
-array; like the following example:
+array like the following example:
```powershell $a = @(
$a = @(
@(Get-Process) )
-[int]$r = $a.Rank
-"`$a rank: $r"
+"`$a rank: $($a.Rank)"
+"`$a length: $($a.Length)"
+"`$a length: $($a.Length)"
+"Process `$a[2][1]: $($a[2][1].ProcessName)"
```
+In this example, you are creating a single-dimensional array that contains
+other arrays. This is also known as a _jagged array_. The **Rank** property
+proved that this is single-dimensional. To access items in a jagged array, the
+indexes must be in separate brackets (`[]`).
+ ```Output $a rank: 1
+$a length: 3
+$a[2] length: 348
+Process $a[2][1]: AcroRd32
```
-The following example shows how to create a truly multidimensional array using
-the .Net Framework.
+Multidimensional arrays are stored in
+[row-major order](https://wikipedia.org/wiki/Row-_and_column-major_order). The following example
+shows how to create a truly multidimensional array.
```powershell
-[int[,]]$rank2 = [int[,]]::new(5,5)
+[string[,]]$rank2 = [string[,]]::New(3,2)
$rank2.rank
+$rank2.Length
+$rank2[0,0] = 'a'
+$rank2[0,1] = 'b'
+$rank2[1,0] = 'c'
+$rank2[1,1] = 'd'
+$rank2[2,0] = 'e'
+$rank2[2,1] = 'f'
+$rank2[1,1]
``` ```Output 2
+6
+d
+```
+
+To access items in a multidimensional array, separate the indexes using a comma
+(`,`) within a single set of brackets (`[]`).
+
+Some operations on a multidimensional array, such as replication and
+concatenation, require that array to be flattened. Flattening turns the array
+into a 1-dimensional array of unconstrained type. The resulting array takes on
+all the elements in row-major order. Consider the following example:
+
+```powershell
+$a = "red",$true
+$b = (New-Object 'int[,]' 2,2)
+$b[0,0] = 10
+$b[0,1] = 20
+$b[1,0] = 30
+$b[1,1] = 40
+$c = $a + $b
+$a.GetType().Name
+$b.GetType().Name
+$c.GetType().Name
+$c
+```
+
+The output shows that `$c` is a 1-dimensional array containing the items from
+`$a` and `$b` in row-major order.
+
+```output
+Object[]
+Int32[,]
+Object[]
+red
+True
+10
+20
+30
+40
``` ## Methods of arrays
Microsoft.PowerShell.Core About Powershell Config (7.1) https://github.com/MicrosoftDocs/PowerShell-Docs/commits/staging/reference/7.1/Microsoft.PowerShell.Core/About/about_PowerShell_Config.md
---
-description: Configuration files for PowerShell Core, replacing Registry configuration.
-keywords: powershell
+description: Configuration files for PowerShell, replacing Registry configuration.
Locale: en-US Previously updated : 11/02/2018 Last updated : 03/12/2021 online version: https://docs.microsoft.com/powershell/module/microsoft.powershell.core/about/about_powershell_config?view=powershell-7.1&WT.mc_id=ps-gethelp schema: 2.0.0 Title: about_PowerShell_Config
Configuration files for PowerShell Core, replacing Registry configuration.
The `powershell.config.json` file contains configuration settings for PowerShell Core. PowerShell loads this configuration at startup. The settings can also be modified at runtime. Previously, these settings were stored in the
-Windows Registry for PowerShell, but are now contained in a file to
-enable configuration on macOS and Linux.
+Windows Registry for PowerShell, but are now contained in a file to enable
+configuration on macOS and Linux.
> [!WARNING]
-> If the `powershell.config.json` file contains invalid JSON
-> PowerShell cannot start an interactive session.
-> If this occurs, you must fix the configuration file.
-
-> [!NOTE]
-> Unrecognized keys or invalid values in the configuration file
-> will be silently ignored.
+> Unrecognized keys or invalid values in the configuration file are silently
+> ignored. If the `powershell.config.json` file contains invalid JSON,
+> PowerShell cannot start an interactive session. If this occurs, you must
+> fix the configuration file.
### AllUsers (shared) configuration
configuration for all PowerShell Core sessions running from that PowerShell
Core installation. > [!NOTE]
-> The `$PSHOME` location is defined as
-> the same directory as the executing System.Management.Automation.dll
-> assembly. This applies to hosted PowerShell SDK instances as well.
+> The `$PSHOME` location is defined as the same directory as the executing
+> System.Management.Automation.dll assembly. This applies to hosted PowerShell
+> SDK instances as well.
### CurrentUser (per-user) configurations
For CurrentUser configurations, this sets the **CurrentUser** execution policy.
Where: -- `<shell-id>` refers to the ID of the current PowerShell host.
- For normal PowerShell Core, this is `Microsoft.PowerShell`.
- In any PowerShell session, you can discover it with `$ShellId`.
+- `<shell-id>` refers to the ID of the current PowerShell host. For normal
+ PowerShell Core, this is `Microsoft.PowerShell`. In any PowerShell session,
+ you can discover it with `$ShellId`.
- `<execution-policy>` refers to a valid execution policy name. The following example sets the execution policy of PowerShell to `RemoteSigned`.
In Windows, the equivalent registry keys can be found in
### PSModulePath
-Overrides a PSModulePath component for this PowerShell session. If the
-configuration is for the current user, sets the CurrentUser module path. If
-the configuration is for all users, sets the AllUser module path.
+Overrides the `PSModulePath` settings for this PowerShell session. If the
+configuration is for the current user, sets the **CurrentUser** module path. If
+the configuration is for all users, sets the **AllUsers** module path.
> [!WARNING]
-> Configuring an AllUsers or CurrentUser module path here
-> will not change the scoped installation location for PowerShellGet modules like [Install-Module](/powershell/module/powershellget/install-module).
-> These cmdlets always use the *default* module paths.
+> Configuring an **AllUsers** or **CurrentUser** module path here does not
+> change the scoped installation location for PowerShellGet cmdlets like
+> [Install-Module](/powershell/module/powershellget/install-module). These
+> cmdlets always use the _default_ module paths.
-If no value is set, the default value for the respective module path component
-will be used. See
-[about_Modules](./about_Modules.md#module-and-dsc-resource-locations-and-psmodulepath)
-for more details on these defaults.
+If no value is set, PowerShell uses the default value for the respective module
+path setting. For more information about these defaults, see
+[about_Modules](./about_Modules.md#module-and-dsc-resource-locations-and-psmodulepath).
This setting allows environment variables to be used by embedding them between `%` characters, like `"%HOME%\Documents\PowerShell\Modules"`, in the same way
-as CMD allows. This syntax also applies on Linux and macOS. See below for
+that CMD allows. This syntax also applies on Linux and macOS. See below for
examples. ```Schema
Where:
configurations, this is the AllUsers shared module directory. For current user configurations, this is CurrentUser module directory.
-This example shows a PSModulePath configuration for a Windows environment:
+This example shows a `PSModulePath` configuration for a Windows environment:
```json {
This example shows a PSModulePath configuration for a Windows environment:
} ```
-This example shows a PSModulePath configuration for a macOS or Linux
+This example shows a `PSModulePath` configuration for a macOS or Linux
environment: ```json
environment:
} ```
-This example shows embedding an environment variable in a PSModulePath
+This example shows embedding an environment variable in a `PSModulePath`
configuration. Note that using the `HOME` environment variable and the `/` directory separator, this will work on Windows, macOS and Linux.
directory separator, this will work on Windows, macOS and Linux.
} ```
-This example shows embedding an environment variable in a PSModulePath
+This example shows embedding an environment variable in a `PSModulePath`
configuration that will only work on macOS and Linux: ```json
configuration that will only work on macOS and Linux:
``` > [!NOTE]
-> PowerShell variables cannot be embedded in PSModulePath configurations.
-> PSModulePath configurations on Linux and macOS are case-sensitive. A
-> PSModulePath configuration must use valid directory separators for the
+> PowerShell variables cannot be embedded in `PSModulePath` configurations.
+> `PSModulePath` configurations on Linux and macOS are case-sensitive. A
+> `PSModulePath` configuration must use valid directory separators for the
> platform. On macOS and Linux, this means `/`. On Windows, both `/` and `\` > will work. ### ExperimentalFeatures
-The names of the experimental features to enable in PowerShell.
-By default, no experimental features are enabled.
-The default value is an empty array.
+The names of the experimental features to enable in PowerShell. By default, no
+experimental features are enabled. The default value is an empty array.
```Schema "ExperimentalFeatures": ["<experimental-feature-name>", ...]
Where:
- `<experimental-feature-name>` is the name of an experimental feature to enable.
-The following example enables the **PSImplicitRemoting**
-and **PSUseAbbreviationExpansion** experimental features
-when PowerShell starts up.
+The following example enables the **PSImplicitRemoting** and
+**PSUseAbbreviationExpansion** experimental features when PowerShell starts up.
```json {
when PowerShell starts up.
} ```
-For more information on experimental features, see [PowerShell RFC 29][RFC0029].
+For more information on experimental features, see
+[Using experimental features](/powershell/scripting/learn/experimental-features).
## Non-Windows logging configuration
Where:
> You may want to have different **LogIdentity** values for each different > instance of PowerShell you have installed.
-In this example, we are configuring the **LogIdentity** for a preview
-release of PowerShell.
+In this example, we are configuring the **LogIdentity** for a preview release
+of PowerShell.
```json {
Where:
- ManagedPlugin - WSMan plugin > [!NOTE]
-> It is generally advised to leave this value unset
-> unless you are trying to diagnose a specific behavior
-> in a known part of PowerShell.
-> Changing this value only decreases the amount of information logged.
+> It is generally advised to leave this value unset unless you are trying to
+> diagnose a specific behavior in a known part of PowerShell. Changing this
+> value only decreases the amount of information logged.
This example limits the logging to runspace operations, pipeline logic, and cmdlet use. All other logging will be omitted.
This configuration sets a number of options that only work in macOS or Linux:
[About Execution Policies](./about_Execution_Policies.md) [About Automatic Variables](./about_Automatic_Variables.md)-
-[RFC0029]: https://github.com/PowerShell/PowerShell-RFC/blob/master/5-Final/RFC0029-Support-Experimental-Features.md
-
Microsoft.PowerShell.Core About Arrays (7.2) https://github.com/MicrosoftDocs/PowerShell-Docs/commits/staging/reference/7.2/Microsoft.PowerShell.Core/About/about_Arrays.md
$a.Length
Returns the number of dimensions in the array. Most arrays in PowerShell have one dimension, only. Even when you think you are building a multidimensional
-array; like the following example:
+array like the following example:
```powershell $a = @(
$a = @(
@(Get-Process) )
-[int]$r = $a.Rank
-"`$a rank: $r"
+"`$a rank: $($a.Rank)"
+"`$a length: $($a.Length)"
+"`$a length: $($a.Length)"
+"Process `$a[2][1]: $($a[2][1].ProcessName)"
```
+In this example, you are creating a single-dimensional array that contains
+other arrays. This is also known as a _jagged array_. The **Rank** property
+proved that this is single-dimensional. To access items in a jagged array, the
+indexes must be in separate brackets (`[]`).
+ ```Output $a rank: 1
+$a length: 3
+$a[2] length: 348
+Process $a[2][1]: AcroRd32
```
-The following example shows how to create a truly multidimensional array using
-the .Net Framework.
+Multidimensional arrays are stored in
+[row-major order](https://wikipedia.org/wiki/Row-_and_column-major_order). The following example
+shows how to create a truly multidimensional array.
```powershell
-[int[,]]$rank2 = [int[,]]::new(5,5)
+[string[,]]$rank2 = [string[,]]::New(3,2)
$rank2.rank
+$rank2.Length
+$rank2[0,0] = 'a'
+$rank2[0,1] = 'b'
+$rank2[1,0] = 'c'
+$rank2[1,1] = 'd'
+$rank2[2,0] = 'e'
+$rank2[2,1] = 'f'
+$rank2[1,1]
``` ```Output 2
+6
+d
+```
+
+To access items in a multidimensional array, separate the indexes using a comma
+(`,`) within a single set of brackets (`[]`).
+
+Some operations on a multidimensional array, such as replication and
+concatenation, require that array to be flattened. Flattening turns the array
+into a 1-dimensional array of unconstrained type. The resulting array takes on
+all the elements in row-major order. Consider the following example:
+
+```powershell
+$a = "red",$true
+$b = (New-Object 'int[,]' 2,2)
+$b[0,0] = 10
+$b[0,1] = 20
+$b[1,0] = 30
+$b[1,1] = 40
+$c = $a + $b
+$a.GetType().Name
+$b.GetType().Name
+$c.GetType().Name
+$c
+```
+
+The output shows that `$c` is a 1-dimensional array containing the items from
+`$a` and `$b` in row-major order.
+
+```output
+Object[]
+Int32[,]
+Object[]
+red
+True
+10
+20
+30
+40
``` ## Methods of arrays
Microsoft.PowerShell.Core About Powershell Config (7.2) https://github.com/MicrosoftDocs/PowerShell-Docs/commits/staging/reference/7.2/Microsoft.PowerShell.Core/About/about_PowerShell_Config.md
---
-description: Configuration files for PowerShell Core, replacing Registry configuration.
+description: Configuration files for PowerShell, replacing Registry configuration.
Locale: en-US Previously updated : 11/02/2018 Last updated : 03/12/2021 online version: https://docs.microsoft.com/powershell/module/microsoft.powershell.core/about/about_powershell_config?view=powershell-7.2&WT.mc_id=ps-gethelp schema: 2.0.0 Title: about_PowerShell_Config
Configuration files for PowerShell Core, replacing Registry configuration.
The `powershell.config.json` file contains configuration settings for PowerShell Core. PowerShell loads this configuration at startup. The settings can also be modified at runtime. Previously, these settings were stored in the
-Windows Registry for PowerShell, but are now contained in a file to
-enable configuration on macOS and Linux.
+Windows Registry for PowerShell, but are now contained in a file to enable
+configuration on macOS and Linux.
> [!WARNING]
-> If the `powershell.config.json` file contains invalid JSON
-> PowerShell cannot start an interactive session.
-> If this occurs, you must fix the configuration file.
-
-> [!NOTE]
-> Unrecognized keys or invalid values in the configuration file
-> will be silently ignored.
+> Unrecognized keys or invalid values in the configuration file are silently
+> ignored. If the `powershell.config.json` file contains invalid JSON,
+> PowerShell cannot start an interactive session. If this occurs, you must
+> fix the configuration file.
### AllUsers (shared) configuration
configuration for all PowerShell Core sessions running from that PowerShell
Core installation. > [!NOTE]
-> The `$PSHOME` location is defined as
-> the same directory as the executing System.Management.Automation.dll
-> assembly. This applies to hosted PowerShell SDK instances as well.
+> The `$PSHOME` location is defined as the same directory as the executing
+> System.Management.Automation.dll assembly. This applies to hosted PowerShell
+> SDK instances as well.
### CurrentUser (per-user) configurations
For CurrentUser configurations, this sets the **CurrentUser** execution policy.
Where: -- `<shell-id>` refers to the ID of the current PowerShell host.
- For normal PowerShell Core, this is `Microsoft.PowerShell`.
- In any PowerShell session, you can discover it with `$ShellId`.
+- `<shell-id>` refers to the ID of the current PowerShell host. For normal
+ PowerShell Core, this is `Microsoft.PowerShell`. In any PowerShell session,
+ you can discover it with `$ShellId`.
- `<execution-policy>` refers to a valid execution policy name. The following example sets the execution policy of PowerShell to `RemoteSigned`.
In Windows, the equivalent registry keys can be found in
### PSModulePath
-Overrides a PSModulePath component for this PowerShell session. If the
-configuration is for the current user, sets the CurrentUser module path. If
-the configuration is for all users, sets the AllUser module path.
+Overrides the `PSModulePath` settings for this PowerShell session. If the
+configuration is for the current user, sets the **CurrentUser** module path. If
+the configuration is for all users, sets the **AllUsers** module path.
> [!WARNING]
-> Configuring an AllUsers or CurrentUser module path here
-> will not change the scoped installation location for PowerShellGet modules like [Install-Module](/powershell/module/powershellget/install-module).
-> These cmdlets always use the *default* module paths.
+> Configuring an **AllUsers** or **CurrentUser** module path here does not
+> change the scoped installation location for PowerShellGet cmdlets like
+> [Install-Module](/powershell/module/powershellget/install-module). These
+> cmdlets always use the _default_ module paths.
-If no value is set, the default value for the respective module path component
-will be used. See
-[about_Modules](./about_Modules.md#module-and-dsc-resource-locations-and-psmodulepath)
-for more details on these defaults.
+If no value is set, PowerShell uses the default value for the respective module
+path setting. For more information about these defaults, see
+[about_Modules](./about_Modules.md#module-and-dsc-resource-locations-and-psmodulepath).
This setting allows environment variables to be used by embedding them between `%` characters, like `"%HOME%\Documents\PowerShell\Modules"`, in the same way
-as CMD allows. This syntax also applies on Linux and macOS. See below for
+that CMD allows. This syntax also applies on Linux and macOS. See below for
examples. ```Schema
Where:
configurations, this is the AllUsers shared module directory. For current user configurations, this is CurrentUser module directory.
-This example shows a PSModulePath configuration for a Windows environment:
+This example shows a `PSModulePath` configuration for a Windows environment:
```json {
This example shows a PSModulePath configuration for a Windows environment:
} ```
-This example shows a PSModulePath configuration for a macOS or Linux
+This example shows a `PSModulePath` configuration for a macOS or Linux
environment: ```json
environment:
} ```
-This example shows embedding an environment variable in a PSModulePath
+This example shows embedding an environment variable in a `PSModulePath`
configuration. Note that using the `HOME` environment variable and the `/` directory separator, this will work on Windows, macOS and Linux.
directory separator, this will work on Windows, macOS and Linux.
} ```
-This example shows embedding an environment variable in a PSModulePath
+This example shows embedding an environment variable in a `PSModulePath`
configuration that will only work on macOS and Linux: ```json
configuration that will only work on macOS and Linux:
``` > [!NOTE]
-> PowerShell variables cannot be embedded in PSModulePath configurations.
-> PSModulePath configurations on Linux and macOS are case-sensitive. A
-> PSModulePath configuration must use valid directory separators for the
+> PowerShell variables cannot be embedded in `PSModulePath` configurations.
+> `PSModulePath` configurations on Linux and macOS are case-sensitive. A
+> `PSModulePath` configuration must use valid directory separators for the
> platform. On macOS and Linux, this means `/`. On Windows, both `/` and `\` > will work. ### ExperimentalFeatures
-The names of the experimental features to enable in PowerShell.
-By default, no experimental features are enabled.
-The default value is an empty array.
+The names of the experimental features to enable in PowerShell. By default, no
+experimental features are enabled. The default value is an empty array.
```Schema "ExperimentalFeatures": ["<experimental-feature-name>", ...]
Where:
- `<experimental-feature-name>` is the name of an experimental feature to enable.
-The following example enables the **PSImplicitRemoting**
-and **PSUseAbbreviationExpansion** experimental features
-when PowerShell starts up.
+The following example enables the **PSImplicitRemoting** and
+**PSUseAbbreviationExpansion** experimental features when PowerShell starts up.
```json {
when PowerShell starts up.
} ```
-For more information on experimental features, see [PowerShell RFC 29][RFC0029].
+For more information on experimental features, see
+[Using experimental features](/powershell/scripting/learn/experimental-features).
## Non-Windows logging configuration
Where:
> You may want to have different **LogIdentity** values for each different > instance of PowerShell you have installed.
-In this example, we are configuring the **LogIdentity** for a preview
-release of PowerShell.
+In this example, we are configuring the **LogIdentity** for a preview release
+of PowerShell.
```json {
Where:
- ManagedPlugin - WSMan plugin > [!NOTE]
-> It is generally advised to leave this value unset
-> unless you are trying to diagnose a specific behavior
-> in a known part of PowerShell.
-> Changing this value only decreases the amount of information logged.
+> It is generally advised to leave this value unset unless you are trying to
+> diagnose a specific behavior in a known part of PowerShell. Changing this
+> value only decreases the amount of information logged.
This example limits the logging to runspace operations, pipeline logic, and cmdlet use. All other logging will be omitted.
This configuration sets a number of options that only work in macOS or Linux:
[About Execution Policies](./about_Execution_Policies.md) [About Automatic Variables](./about_Automatic_Variables.md)-
-[RFC0029]: https://github.com/PowerShell/PowerShell-RFC/blob/master/5-Final/RFC0029-Support-Experimental-Features.md
-
developer Modifying The Psmodulepath Installation Path https://github.com/MicrosoftDocs/PowerShell-Docs/commits/staging/reference/docs-conceptual/developer/module/modifying-the-psmodulepath-installation-path.md
--- Previously updated : 09/13/2016 Last updated : 03/12/2021 Title: Modifying the PSModulePath Installation Path description: Modifying the PSModulePath Installation Path
To add paths to this variable, use one of the following methods:
- To add a persistent value that is available whenever a session is opened, add the above command to a PowerShell profile file (`$PROFILE`)>
- For more information about profiles, see [about_Profiles](/powershell/module/microsoft.powershell.core/about/about_profiles).
+ For more information about profiles, see
+ [about_Profiles](/powershell/module/microsoft.powershell.core/about/about_profiles).
- To add a persistent variable to the registry, create a new user environment variable called `PSModulePath` using the Environment Variables Editor in the **System Properties** dialog box. -- To add a persistent variable by using a script, use the .Net method [SetEnvironmentVariable](/dotnet/api/system.environment.setenvironmentvariable)
- on the [System.Environment](/dotnet/api/system.environment) class. For
- example, the following script adds the `C:\Program Files\Fabrikam\Module` path to the value of the
- `PSModulePath` environment variable for the computer. To add the path to the user `PSModulePath`
- environment variable, set the target to "User".
+- To add a persistent variable by using a script, use the .Net method
+ [SetEnvironmentVariable](/dotnet/api/system.environment.setenvironmentvariable) on the
+ [System.Environment](/dotnet/api/system.environment) class. For example, the following script adds
+ the `C:\Program Files\Fabrikam\Module` path to the value of the `PSModulePath` environment
+ variable for the computer. To add the path to the user `PSModulePath` environment variable, set
+ the target to "User".
```powershell $CurrentValue = [Environment]::GetEnvironmentVariable("PSModulePath", "Machine")
To add paths to this variable, use one of the following methods:
```
+You may also set the `PSModulePath` values in the `powershell.config.json` configuration file. For
+more information, see
+[about_PowerShell_Config](/powershell/module/microsoft.powershell.core/about/about_powershell_config#psmodulepath).
+ ## To remove locations from the PSModulePath
-You can remove paths from the variable using similar methods: for example, `$env:PSModulePath = $env:PSModulePath -replace "$([System.IO.Path]::PathSeparator)c:\\ModulePath"`
+You can remove paths from the variable using similar methods: for example,
+`$env:PSModulePath = $env:PSModulePath -replace "$([System.IO.Path]::PathSeparator)c:\\ModulePath"`
will remove the **c:\ModulePath** path from the current session. ## See Also