PowerShell (including Windows PowerShell and PowerShell Core) is a task automation and

configuration management framework from Microsoft, consisting of a command-line shell and

associated scripting language built on the .NET Framework. PowerShell provides full access to
COM and WMI, enabling administrators to perform administrative tasks on both local and
remote Windows systems as well as WS-Management and CIM enabling management of remote
Linux systems and network devices. Initially a Windows component only, PowerShell was made
open-source and cross-platform on 18 August 2016.[3]
In PowerShell, administrative tasks are generally performed by cmdlets (pronounced commandlets), which are specialized .NET classes implementing a particular operation. Sets of cmdlets
may be combined into scripts, executables (which are standalone applications), or by
instantiating regular .NET classes (or WMI/COM Objects).[4][5] These work by accessing data in
different data stores, like the file system or registry, which are made available to the PowerShell
runtime via PowerShell providers.
PowerShell also provides a hosting API with which the PowerShell runtime can be embedded
inside other applications. These applications can then use PowerShell functionality to implement
certain operations, including those exposed via the graphical interface. This capability has been
used by Microsoft Exchange Server 2007 to expose its management functionality as PowerShell
cmdlets and providers and implement the graphical management tools as PowerShell hosts which
invoke the necessary cmdlets.[4][6] Other Microsoft applications including Microsoft SQL Server
2008 also expose their management interface via PowerShell cmdlets.[7]
PowerShell includes its own extensive, console-based help, similar to man pages in Unix shells,
via the Get-Help cmdlet. Local help contents can be retrieved from the Internet via UpdateHelp cmdlet. Alternatively, help from the web can be acquired on a case-by-case basis via the online switch to Get-Help.

Contents
[hide]

1 Background
2 Design
o 2.1 Cmdlets
o 2.2 Pipeline
o 2.3 Scripting
o 2.4 Hosting
3 Desired State Configuration
4 Versions
o 4.1 PowerShell 1.0
o 4.2 PowerShell 2.0
o 4.3 PowerShell 3.0
o 4.4 PowerShell 4.0
o 4.5 PowerShell 5.0
5 Comparison of cmdlets with similar commands

6 File extensions
7 Application support
o 7.1 Snap-ins and hosts
8 Alternative implementation
9 See also
10 References
11 Further reading
12 External links

Background[edit]
Every released version of Microsoft DOS and Microsoft Windows for personal computers has
included a command-line interface tool (shell). These are COMMAND.COM (in installations relying
on MS-DOS, including Windows 9x) and cmd.exe (in Windows NT family operating systems).
The shell is a command line interpreter that supports a few basic commands. For other purposes,
a separate console application must be invoked from the shell. The shell also includes a scripting
language (batch files), which can be used to automate various tasks. However, the shell cannot
be used to automate all facets of GUI functionality, in part because command-line equivalents of
operations exposed via the graphical interface are limited, and the scripting language is
elementary and does not allow the creation of complex scripts. In Windows Server 2003, the
situation was improved, but scripting support was still considered unsatisfactory.[8]
Microsoft attempted to address some of these shortcomings by introducing the Windows Script
Host in 1998 with Windows 98, and its command-line based host: cscript.exe. It integrates
with the Active Script engine and allows scripts to be written in compatible languages, such as
JScript and VBScript, leveraging the APIs exposed by applications via COM. However, it has its
own deficiencies: it is not integrated with the shell, its documentation is not very accessible, and
it quickly gained a reputation as a system vulnerability vector after several high-profile computer
viruses exploited weaknesses in its security provisions. Different versions of Windows provided
various special-purpose command line interpreters (such as netsh and WMIC) with their own
command sets. None of them were integrated with the command shell; nor were they
interoperable.
By 2002 Microsoft had started to develop a new approach to command line management,
including a shell called Monad (also known as Microsoft Shell or MSH). The shell and the ideas
behind it were published in August 2002 in a white paper entitled Monad Manifesto.[9] Monad
was to be a new extensible command shell with a fresh design that would be capable of
automating a full range of core administrative tasks. Microsoft first showed off Monad at the
Professional Development Conference in Los Angeles in October 2003. A private beta program
began a few months later which eventually led to a public beta program.
Microsoft published the first Monad public beta release on June 17, 2005, Beta 2 on September
11, 2005, and Beta 3 on January 10, 2006. Not much later, on April 25, 2006 Microsoft formally
announced that Monad had been renamed Windows PowerShell, positioning it as a significant
part of their management technology offerings.[10] Release Candidate 1 of PowerShell was

released at the same time. A significant aspect of both the name change and the RC was that this
was now a component of Windows, and not an add-on product.
Release Candidate 2 of PowerShell version 1 was released on September 26, 2006 with final
Release to the web (RTW) on November 14, 2006 and announced at TechEd Barcelona.
PowerShell for earlier versions of Windows was released on January 30, 2007.[11]
PowerShell v2.0 development began before PowerShell v1.0 shipped. During the development,
Microsoft shipped three community technology preview (CTP). Microsoft made these releases
available to the public. The last CTP release of Windows PowerShell v2.0 was made available in
December 2008.

PowerShell for Linux 6.0 Alpha 9 on Ubuntu 14.04 x64

PowerShell v2.0 was completed and released to manufacturing in August 2009, as an integral
part of Windows 7 and Windows Server 2008 R2. Versions of PowerShell for Windows XP,
Windows Server 2003, Windows Vista and Windows Server 2008 were released in October 2009
and are available for download for both 32-bit and 64-bit platforms.[12]
Windows 10 shipped a testing framework for PowerShell.[13]
On 18 August 2016, Microsoft announced[14] that they had made PowerShell open-source and
cross-platform with support for Windows, OS X, CentOS and Ubuntu.[3] The source code was
published on GitHub. [15] The move to open source created a second incarnation of PowerShell
called "PowerShell Core", which runs on .NET Core. It is distinct from "Windows PowerShell",
which runs on the full .NET Framework.[16] PowerShell Core will be shipped with Windows
Server 2016 Nano Server.[17]

Design[edit]
PowerShell's developers based the core grammar of the tool on that of POSIX 1003.2.[18]
Windows PowerShell can execute four kinds of named commands:[19]

cmdlets (.NET Framework programs designed to interact with PowerShell)

PowerShell scripts (files suffixed by .ps1)
PowerShell functions
standalone executable programs

If a command is a standalone executable program, PowerShell.exe launches it in a separate

process; if it is a cmdlet, it executes in the PowerShell process. PowerShell provides an
interactive command-line interface, wherein the commands can be entered and their output
displayed. The user interface, based on the Win32 console, offers customizable tab completion.
PowerShell enables the creation of aliases for cmdlets, which PowerShell textually translates
into invocations of the original commands. PowerShell supports both named and positional
parameters for commands. In executing a cmdlet, the job of binding the argument value to the
parameter is done by PowerShell itself, but for external executables, arguments are parsed by the
external executable independently of PowerShell interpretation.[citation needed]
The PowerShell Extended Type System (ETS) is based on the .NET type system, but with
extended semantics (for example, propertySets and third-party extensibility). For example, it
enables the creation of different views of objects by exposing only a subset of the data fields,
properties, and methods, as well as specifying custom formatting and sorting behavior. These
views are mapped to the original object using XML-based configuration files.[20]

Cmdlets[edit]
Cmdlets are specialized commands in the PowerShell environment that implement specific
functions. These are the native commands in the PowerShell stack. Cmdlets follow a Verb-Noun
naming pattern, such as Get-ChildItem, helping to make them self-descriptive.[21] Cmdlets output
their results as objects or as collections thereof (including arrays), and can optionally receive
input in that form, making them suitable for use as recipients in a pipeline. But whereas
PowerShell allows arrays and other collections of objects to be written to the pipeline, cmdlets
always process objects individually. For collections of objects, PowerShell invokes the cmdlet on
each object in the collection, in sequence.[21]
Cmdlets are specialized .NET classes, which the PowerShell runtime instantiates and invokes at
run-time. Cmdlets derive either from Cmdlet or from PSCmdlet, the latter being used when the
cmdlet needs to interact with the PowerShell runtime.[21] These base classes specify certain
methods - BeginProcessing(), ProcessRecord() and EndProcessing() which the cmdlet's
implementation overrides to provide the functionality. Whenever a cmdlet runs, PowerShell
invokes these methods in sequence, with ProcessRecord() being called if it receives pipeline
input.[22] If a collection of objects is piped, the method is invoked for each object in the collection.
The class implementing the Cmdlet must have one .NET attribute - CmdletAttribute which
specifies the verb and the noun that make up the name of the cmdlet. Common verbs are
provided as an enum.>[23][24]
If a cmdlet receives either pipeline input or command-line parameter input, there must be a
corresponding property in the class, with a mutator implementation. PowerShell invokes the
mutator with the parameter value or pipeline input, which is saved by the mutator
implementation in class variables. These values are then referred to by the methods which
implement the functionality. Properties that map to command-line parameters are marked by
ParameterAttribute[25] and are set before the call to BeginProcessing(). Those which map to
pipeline input are also flanked by ParameterAttribute, but with the ValueFromPipeline
attribute parameter set.[26]

The implementation of these cmdlet classes can refer to any .NET API and may be in any .NET
language. In addition, PowerShell makes certain APIs available, such as WriteObject(), which
is used to access PowerShell-specific functionality, such as writing resultant objects to the
pipeline. Cmdlets can use .NET data access APIs directly or use the PowerShell infrastructure of
PowerShell Providers, which make data stores addressable using unique paths. Data stores are
exposed using drive letters, and hierarchies within them, addressed as directories. Windows
PowerShell ships with providers for the file system, registry, the certificate store, as well as the
namespaces for command aliases, variables, and functions.[27] Windows PowerShell also includes
various cmdlets for managing various Windows systems, including the file system, or using
Windows Management Instrumentation to control Windows components. Other applications can
register cmdlets with PowerShell, thus allowing it to manage them, and, if they enclose any
datastore (such as databases), they can add specific providers as well.[citation needed]
PowerShell V2 added a more portable version of Cmdlets called Modules. The PowerShell V2
release notes state:
"Modules allow script developers and administrators to partition and organize their Windows
PowerShell code in self-contained, reusable units. Code from a module executes in its own selfcontained context and does not affect the state outside of the module. Modules also enable you to
define a restricted runspace environment by using a script."[citation needed]

Pipeline[edit]
PowerShell implements the concept of a pipeline, which enables piping the output of one cmdlet
to another cmdlet as input. For example, the output of the Get-Process cmdlet could be piped to
the Where-Object to filter any process that has less than 1 MB of paged memory, and then to the
Sort-Object cmdlet (e.g., to sort the objects by handle count), and then finally to the SelectObject cmdlet to select just the first 10 (i.e., the 10 processes based on handle count).[citation needed]
As with Unix pipelines, PowerShell pipelines can construct complex commands, using the |
operator to connect stages. However, the PowerShell pipeline differs from Unix pipelines in that
stages execute within the PowerShell runtime rather than as a set of processes coordinated by the
operating system, and structured .NET objects, rather than byte streams, are passed from one
stage to the next. Using objects and executing stages within the PowerShell runtime eliminates
the need to serialize data structures, or to extract them by explicitly parsing text output.[28] An
object can also encapsulate certain functions that work on the contained data, which become
available to the recipient command for use.[29][30] For the last cmdlet in a pipeline, PowerShell
automatically pipes its output object to the Out-Default cmdlet, which transforms the objects
into a stream of format objects and then renders those to the screen.[31][32]
Because all PowerShell objects are .NET objects, they share a .ToString() method, which
retrieves the text representation of the data in an object. In addition, PowerShell allows
formatting definitions to be specified, so the text representation of objects can be customized by
choosing which data elements to display, and in what manner. However, in order to maintain
backwards compatibility, if an external executable is used in a pipeline, it receives a text stream
representing the object, instead of directly integrating with the PowerShell type system.[33][34][35]

Scripting[edit]
Windows PowerShell includes a dynamically typed scripting language which can implement
complex operations using cmdlets imperatively. The scripting language supports variables,
functions, branching (if-then-else), loops (while, do, for, and foreach), structured
error/exception handling and closures/lambda expressions,[36] as well as integration with .NET.
Variables in PowerShell scripts are prefixed with $. Variables can be assigned any value,
including the output of cmdlets. Strings can be enclosed either in single quotes or in double
quotes: when using double quotes, variables will be expanded even if they are inside the
quotation marks. Enclosing the path to a file in braces preceded by a dollar sign (as in
${C:\foo.txt}) creates a reference to the contents of the file. If it is used as an L-value,
anything assigned to it will be written to the file. When used as an R-value, the contents of the
file will be read. If an object is assigned, it is serialized before being stored.[citation needed]
Object members can be accessed using . notation, as in C# syntax. PowerShell provides special
variables, such as $args, which is an array of all the command line arguments passed to a
function from the command line, and $_, which refers to the current object in the pipeline.[37]
PowerShell also provides arrays and associative arrays. The PowerShell scripting language also
evaluates arithmetic expressions entered on the command line immediately, and it parses
common abbreviations, such as GB, MB, and KB.[38][39]
Using the function keyword, PowerShell provides for the creation of functions, the following
general form:[40]
function name ($Param1, $Param2)
{
Instructions
}

The defined function is invoked in either of the following forms:[40]

name value1 value2
name -Param1 value1 -Param2 value2

PowerShell supports named parameters, positional parameters, switch parameters and dynamic
parameters.[40]
PowerShell allows any .NET methods to be called by providing their namespaces enclosed in
brackets ([]), and then using a pair of colons (::) to indicate the static method.[41] For example,
[System.Console]::WriteLine("PowerShell"). Objects are created using the New-Object
cmdlet. Calling methods of .NET objects is accomplished by using the regular . notation.[41]
PowerShell scripting language accepts strings, both raw and escaped. A string enclosed between
single quotation marks is a raw string while a string enclosed between double quotation marks is
an escaped string. PowerShell treats straight and curly quotes as equivalent.[42]

For error handling, PowerShell provides a .NET-based exception-handling mechanism. In case

of errors, objects containing information about the error (Exception object) are thrown, which
are caught using the try ... catch construct (although a trap construct is supported as well).
However, the action-or-error is configurable; in case of an error, PowerShell can be configured
to silently resume execution, without actually throwing the exception.[43]
Scripts written using PowerShell can be made to persist across sessions in either a .ps1 file or a
.psm1 file (the latter is used to implement a module). Later, either the entire script or individual
functions in the script can be used. Scripts and functions operate analogously with cmdlets, in
that they can be used as commands in pipelines, and parameters can be bound to them. Pipeline
objects can be passed between functions, scripts, and cmdlets seamlessly. To prevent
unintentional running of scripts, script execution is disabled by default and must be enabled
explicitly.[44] Enabling of scripts can be performed either at system, user or session level.
PowerShell scripts can be signed to verify their integrity, and are subject to Code Access
Security.[45]
The PowerShell scripting language supports binary prefix notation similar to the scientific
notation supported by many programming languages in the C-family.[46][better source needed]

Hosting[edit]
One can also use PowerShell embedded in a management application, which uses the PowerShell
runtime to implement the management functionality. For this, PowerShell provides a managed
hosting API. Via the APIs, the application can instantiate a runspace (one instantiation of the
PowerShell runtime), which runs in the application's process and is exposed as a Runspace
object.[4] The state of the runspace is encased in a SessionState object. When the runspace is
created, the Windows PowerShell runtime initializes the instantiation, including initializing the
providers and enumerating the cmdlets, and updates the SessionState object accordingly. The
Runspace then must be opened for either synchronous processing or asynchronous processing.
After that it can be used to execute commands.[citation needed]
To execute a command, a pipeline (represented by a Pipeline object) must be created and
associated with the runspace. The pipeline object is then populated with the cmdlets that make up
the pipeline. For sequential operations (as in a PowerShell script), a Pipeline object is created for
each statement and nested inside another Pipeline object.[4] When a pipeline is created, Windows
PowerShell invokes the pipeline processor, which resolves the cmdlets into their respective
assemblies (the command processor) and adds a reference to them to the pipeline, and associates
them with InputPipe, Outputpipe and ErrorOutputPipe objects, to represent the connection
with the pipeline. The types are verified and parameters bound using reflection.[4] Once the
pipeline is set up, the host calls the Invoke() method to run the commands, or its asynchronous
equivalent - InvokeAsync(). If the pipeline has the Write-Host cmdlet at the end of the
pipeline, it writes the result onto the console screen. If not, the results are handed over to the
host, which might either apply further processing or display the output itself.[citation needed]
Microsoft Exchange Server 2007 uses the hosting APIs to provide its management GUI. Each
operation exposed in the GUI is mapped to a sequence of PowerShell commands (or pipelines).

The host creates the pipeline and executes them. In fact, the interactive PowerShell console itself
is a PowerShell host, which interprets the scripts entered at command line and creates the
necessary Pipeline objects and invokes them.[citation needed]

Desired State Configuration[edit]

DSC allows for declaratively specifying how a software environment should be configured.[47]
Upon running a configuration, DSC will ensure that the system gets the state described in the
configuration. DSC configurations are idempotent. The Local Configuration Manager (LCM)
periodically polls the system using the control flow described by resources (imperative pieces of
DSC) to make sure that the state of a configuration is maintained.

Versions[edit]
Initially using the code name "Monad", PowerShell was first shown publicly at the Professional
Developers Conference in September 2003. All major releases are still supported, and each
major release has featured backwards compatibility with preceding versions.

PowerShell 1.0[edit]
PowerShell 1.0 was released in November 2006 for Windows XP SP2, Windows Server 2003
and Windows Vista. It is an optional component of Windows Server 2008.[48]

PowerShell 2.0[edit]

Windows PowerShell ISE v2.0, an integrated development environment for PowerShell scripts
PowerShell 2.0 is integrated with Windows 7 and Windows Server 2008 R2[49] and is released for
Windows XP with Service Pack 3, Windows Server 2003 with Service Pack 2, and Windows
Vista with Service Pack 1.[50][51]
PowerShell V2 includes changes to the scripting language and hosting API, in addition to
including more than 240 new cmdlets.[52][53]
New features of PowerShell 2.0 include:[54][55][56]

PowerShell Remoting: Using WS-Management, PowerShell 2.0 allows scripts and

cmdlets to be invoked on a remote machine or a large set of remote machines.
Background Jobs: Also called a PSJob, it allows a command sequence (script) or
pipeline to be invoked asynchronously. Jobs can be run on the local machine or on
multiple remote machines. An interactive cmdlet in a PSJob blocks the execution of the
job until user input is provided.
Transactions: Enable cmdlet and developers can perform transactional operations.
PowerShell 2.0 includes transaction cmdlets for starting, committing, and rolling back a
PSTransaction as well as features to manage and direct the transaction to the
participating cmdlet and provider operations. The PowerShell Registry provider supports
transactions.
ScriptCmdlets: These are cmdlets written using the PowerShell scripting language. The
preferred[by whom?] name for script cmdlets is now[when?] Advanced Functions.[citation needed]
SteppablePipelines: This allows the user to control when the BeginProcessing(),
ProcessRecord() and EndProcessing() functions of a cmdlet are called.
Modules: This allows script developers and administrators to organize and partition
PowerShell scripts in self-contained, reusable units. Code from a module executes in its
own self-contained context and does not affect the state outside the module. Modules can
define a restricted runspace environment by using a script. They have a persistent state as
well as public and private members.
Data Language: A domain-specific subset of the PowerShell scripting language that
allows data definitions to be decoupled from the scripts and allows localized string
resources to be imported into the script at runtime (Script Internationalization).
Script Debugging: It allows breakpoints to be set in a PowerShell script or function.
Breakpoints can be set on lines, line & columns, commands and read or write access of
variables. It includes a set of cmdlets to control the breakpoints via script.
Eventing: This feature allows listening, forwarding, and acting on management and
system events. Eventing allows PowerShell hosts to be notified about state changes to
their managed entities. It also enables PowerShell scripts to subscribe to ObjectEvents,
PSEvents, and WmiEvents and process them synchronously and asynchronously.
Windows PowerShell Integrated Scripting Environment (ISE): PowerShell 2.0
includes a GUI-based PowerShell host that provides integrated debugger, syntax
highlighting, tab completion and up to 8 PowerShell Unicode-enabled consoles
(Runspaces) in a tabbed UI, as well as the ability to run only the selected parts in a script.
Network File Transfer: Native support for prioritized, throttled, and asynchronous
transfer of files between machines using the Background Intelligent Transfer Service
(BITS).[57]
New Cmdlets: Including Out-GridView, which displays tabular data in the WPF
GridView object.
New Operators: -Split, -Join, and Splatting (@) operators.
Exception Handling with Try-Catch-Finally: Unlike other .NET languages, this allows
multiple exception types for a single catch block.
Nestable Here-Strings: PowerShell Here-Strings have been improved and can now
nest.[58]
Block Comments: PowerShell 2.0 supports block comments using <# and #> as
delimiters.[59]

New APIs: The new APIs range from handing more control over the PowerShell parser
and runtime to the host, to creating and managing collection of Runspaces
(RunspacePools) as well as the ability to create Restricted Runspaces which only allow a
configured subset of PowerShell to be invoked. The new APIs also support participation
in a Windows PowerShell managed transaction.

PowerShell 3.0[edit]
PowerShell 3.0 is integrated with Windows 8 and with Windows Server 2012. Microsoft has also
made PowerShell 3.0 available for Windows 7 with Service Pack 1, for Windows Server 2008
with Service Pack 1, and for Windows Server 2008 R2 with Service Pack 1.[60][61]
PowerShell 3.0 is part of a larger package, Windows Management Framework 3.0 (WMF3),
which also contains the WinRM service to support remoting.[61] Microsoft made several
Community Technology Preview releases of WMF3. An early community technology preview 2
(CTP 2) version of Windows Management Framework 3.0 was released on 2 December 2011.[62]
Since then, updated versions have been shipped in the Windows 8 and Server 2012 beta and
release candidate versions.[citation needed]
New features in PowerShell 3.0 include:[61][63]:3334

Scheduled jobs: Jobs can be scheduled to run on a preset time and date.
Session connectivity: Sessions can be disconnected and reconnected. Remote sessions
have become more tolerant of temporary network failures.
Improved code writing: Code completion (IntelliSense) and snippets are added.
PowerShell ISE allows users to use dialog boxes to fill in parameters for PowerShell
cmdlets.
Delegation support: Administrative tasks can be delegated to users who do not have
permissions for that type of task, without granting them perpetual additional permissions.
Help update: Help documentations can be updated via Update-Help command.
Automatic module detection: Modules are loaded implicitly whenever a command from
that module is invoked. Code completion works for unloaded modules as well.
New commands: Dozens of new modules were added, including functionality to manage
disks, volumes, firewalls, network connections and printer management, previously
performed via WMI.[further explanation needed]

PowerShell 4.0[edit]
PowerShell 4.0 is integrated with Windows 8.1 and with Windows Server 2012 R2. Microsoft
has also made PowerShell 4.0 available for Windows 7 SP1, Windows Server 2008 R2 SP1 and
Windows Server 2012.[64]
New features in PowerShell 4.0 include:

Desired State Configuration[65][66][67]: Declarative language extensions and tools that

enable the deployment and management of configuration data for systems using the
DMTF management standards and WS-Management Protocol.
New Default Execution Policy: On Windows Servers, the default execution Policy is
now RemoteSigned
Save-Help: Help can now be saved for modules that are installed on remote computers.
Enhanced debugging: The debugger now supports debugging workflows, remote script
execution and preserving debugging sessions across PowerShell session reconnections.
-PipelineVariable switch: A new ubiquitous parameter to expose the current pipeline
object as a variable for programming purposes.
Network diagnostics to manage physical and Hyper-V's virtualized network switches.
Where and ForEach method syntax provides an alternate method of filtering and
iterating over objects.

PowerShell 5.0[edit]
Windows Management Framework (WMF) 5.0 RTM which includes PowerShell 5.0 was rereleased to web on February 24, 2016, following an initial release with a severe bug.[68] Key
features include OneGet PowerShell cmdlets to support Chocolatey's repository-based package
management[69] and extending support for switch management to layer 2 network switches.[70]
New features in PowerShell 5.0 include:

PowerShell class definitions (properties, methods)

PowerShell .NET Enumerations
Debugging for PowerShell Runspaces in remote processes
Debugging for PowerShell Background Jobs
Desired State Configuration (DSC) Local Configuration Manager (LCM) version 2.0
DSC partial configurations
DSC Local Configuration Manager meta-configurations
Authoring of DSC resources using PowerShell classes

PowerShell 5.1 was released on August 2, 2016, in the Windows 10 Anniversary Update.[71]
PackageManagement now supports proxies, PSReadLine now has ViMode support, and two new
cmdlets were added: Get-TimeZone and Set-TimeZone. The LocalAccounts module allows for
adding/removing local user accounts.[72]

Comparison of cmdlets with similar commands[edit]

The following table contains a selection of the cmdlets that ship with PowerShell, noting similar
commands in other well-known command-line interpreters. Many of these similar commands
come out-of-the-box defined as aliases within PowerShell, making it easy for people familiar
with other common shells to start working.

PowerShell
(Cmdlet)
GetChildItem

PowerShell
(Alias)

CMD.EXE /
Unix shell
COMMAND.COM

Description
List all files / directories in
the (current) directory
Sends ICMP echo requests to
specified machine from the
current machine, or instructs
another machine to do so
Get the content of a file

gci, dir, ls

dir

ls

TestConnection[a]

N/A

ping

ping

Get-Content

gc, type, cat

type

GetCommand

gcm

help

Get-Help

help, man

help

Clear-Host

cls, clear

cls

cat
type,
which,
compgen
apropos,
man
clear

Copy-Item

cpi, copy, cp

copy

cp

Move-Item mi, move, mv

move

mv

del, erase, rmdir, rd

rm, rmdir

Delete a file / a directory

ren, rename

mv

Rename a file / a directory

Display the current
directory/present working
directory.
Change the current directory
to the directory most recently
pushed onto the stack
Push the current directory
onto the stack
Change the current directory
Pipe input to a file or
variable, then pass the input
along the pipeline
Print strings, variables etc. to
standard output
List all currently running
processes
Stop a running process
Print lines matching a pattern

ri, del, erase,

rmdir, rd, rm
Rename-Item rni, ren, mv
Remove-Item

Get-Location

gl, cd, pwd

cd

pwd

Pop-Location

popd

popd

popd

PushLocation
Set-Location

pushd

pushd

pushd

sl, cd, chdir

cd, chdir

cd

Tee-Object

tee

N/A

tee

WriteOutput

echo, write

echo

echo

Get-Process

gps, ps

tlist,[c] tasklist[d]

ps

Stop-Process
Select-String

spps, kill
sls

kill,[c] taskkill[d]
find, findstr

kill[e]
grep

List available commands

Help on commands
Clear the screen[b]
Copy one or several files / a
whole directory tree
Move a file / a directory to a
new location

Set-Variable

sv, set

set

InvokeWebRequest

iwr, curl,
wget

N/A

env,
Set the value of a variable /
export, set,
create a variable
setenv
Gets content from a web page
wget, curl
on the Internet