Powershell: Cmdlet Aliases, Automatic Variables and other Shortcuts

Some notes on the items listed in the title 😉

Misc.

Comments
Use # ... for single-line comments.
Use <# ... #> for multi-line/block (or embedded!) comments.
Set-StrictMode
Set-StrictMode -Version Latest enables and enforces coding rules and best practices in expressions, scripts, and script blocks.

By default, Set-StrictMode is turned off to prevent error messages while you are writing the script.
When strict mode is on, PowerShell generates a terminating error when the content of an expression, script, or script block violates basic best-practice coding rules.

Set-StrictMode affects only the current scope and its child scopes.
Therefore, you can use it in a script or function to override the setting inherited from the global scope.\

  • -Off turns the strict mode off again.

  • -Version <1.0|2.0|3.0|Latest>.
    The latest version is the most strict. Use this value to make sure that scripts use the strictest available version, even when new versions are added to PowerShell.

    Caution: The meaning of Latest can change in new releases of PowerShell. Meaning, a script written for an older version of PowerShell that uses the latest version is subject to more restrictive rules when run in a newer version of PowerShell.

Tip: Put this in your Powershell profile file.

$PSVersionTable
Holds information about the version of your Powershell instance.
$PWD
Contains a path object that represents the full path of the current working directory.
% { ... }
Shortcut for ForEach { ... }, which in turn is a shortcut for ForEach-Object { ... }.
? { ... }
Shortcut for Where { ... }, which in turn is a shortcut for Where-Object { ... }.
$_ or $PSItem
The current object in the pipeline object; or in a Param() block part like [ValidateScript({...})].
$PSBoundParameters
A hashtable containing the parameters passed to a script or a function. Only includes the values of parameters that were explicitly supplied, not those that have been left with a default value!
$Args
An array of values for undeclared parameters that are passed to a function, script, or script block.
$Input
Contains an enumerator [not an array! Rather a kind of an ‘iterator’ in C++ lingo, I’d say –so] that enumerates all input that is passed to a function. The $input variable is available only to functions and script blocks (which are unnamed functions).
  • In a function without a Begin, Process, or End block, the $input variable enumerates the collection of all input to the function.
  • In the Begin block, the $input variable contains no data.
  • In the Process block, the $input variable contains the object that is currently in the pipeline.
  • In the End block, the $input variable enumerates the collection of all input to the function.

Note: You cannot use the $input variable inside both the Process block and the End block in the same function or script block.

Since $input is an enumerator, accessing any of it’s properties causes $input to no longer be available. You can store $input in another variable to reuse the $input properties.

Enumerators contain properties and methods you can use to retrieve loop values and change the current loop iteration. For more information, see Using Enumerators.

$OFS
The Output Field Separator is an Automatic Variable in Powershell which contains a value that is used when converting an array to a string.

By default, $OFS is " " (a space character), but that can be changed:
$private:OFS = "" # nothing
$private:OFS = ";" # semicolon

Example:

> $a = 1, 2, 3
> $a
1
2
3
    
> [string] $s = $a
> $s
1 2 3
    
> $private:OFS = ";"
> [string] $s = $a
> $s
1;2;3

How to get the path or name to the script, its parent folder, or a function

Note that these work only in a script or function, but not on the shell/console itself!

# test.ps1

write-host "1. File scope....: $($MyInvocation.MyCommand.Path)"
write-host "2. File scope....: $($MyInvocation.MyCommand.Name)"
write-host "3. File scope....: $($PSCommandPath)"
write-host "4. File scope....: $($MyInvocation.PSCommandPath)"
write-host "5. File scope....: $($MyInvocation.ScriptName)"
write-host "6. File scope....: $($PSScriptRoot)"

function FunctionX
{
    write-host "A. Function scope: $($script:MyInvocation.MyCommand.Path)" # See note [1].
    write-host "B. Function scope: $($MyInvocation.MyCommand.Name)"
    write-host "C. Function scope: $($PSCommandPath)"
    write-host "D. Function scope: $($MyInvocation.PSCommandPath)"
    write-host "E. Function scope: $($MyInvocation.ScriptName)"
    write-host "F. Function scope: $($PSScriptRoot)"
    
    # [1] The prefix "$script:..." is required in this case; otherwise one will get
    #     a PropertyNotFoundException for 'Path'!
}

FunctionX

Output:

> .\test.ps1

1. File scope....: C:\dev\test\test.ps1
2. File scope....: test.ps1
3. File scope....: C:\dev\test\test.ps1
4. File scope....:                      # Empty
5. File scope....:                      # Empty
6. File scope....: C:\dev\test
A. Function scope: C:\dev\test\test.ps1
B. Function scope: FunctionXYZ
C. Function scope: C:\dev\test\test.ps1
D. Function scope: C:\dev\test\test.ps1
E. Function scope: C:\dev\test\test.ps1
F. Function scope: C:\dev\test

Also note that some outputs may look identical, but the variables can have very different types:

> $MyInvocation.GetType().FullName
System.Management.Automation.InvocationInfo

> $PSScriptRoot.GetType().FullName
System.String

> $PSCommandPath.GetType().FullName
System.String