May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Windows Powershell


See also

Recommended Books Recommended Links Windows PowerShell Shortcut Keys Windows Powershell oneliners

Windows PowerShell Pipelines

Windows XP Slow Startup and Shutdown

Note: Partially based on Windows PowerShell - Wikipedia, the free encyclopedia

Initially using the code name "Monad", PowerShell was first shown publicly at the Professional Developers Conference in September 2003. It feature strong influence of ksh and Perl. It also is the first shell with "structured pipelines" (XML instead of text). There are currently two versions of PowerShell verstion 1 and version 2:

Version 2.0 is a part of so called the Windows Management Framework on Windows XP, Windows Server 2003, Windows Vista, Windows 7 and Windows Server 2008. The Windows Management Framework includes the following:

There are four kinds of commands Windows PowerShell can execute:

If a command is an executable program, PowerShell launches it in a separate process; if it is a cmdlet, it is executed in the PowerShell process. PowerShell also 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 and "arrow" history browsing like in C-shell.

PowerShell also enables the creation of aliases for cmdlets, which are textually translated by PowerShell into invocations of the original commands. PowerShell also 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 passed via the argv (or equivalent) variable array to be parsed by the executable.

Another concept used by PowerShell is that of a pipeline.  They tried to extend Unix pipleine to relational database format, when each record is a set of named fileds.  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.

Because all PowerShell objects are .NET objects, they share a .ToString() method, which retrieves the text representation of the data in an object. Windows PowerShell uses this method to convert an object to text. In addition, it also allows formatting definitions to be specified, so the text representation of objects may be customized by choosing which data elements to display, and how. However, in order to maintain backwards compatibility, if an external executable is used in a pipeline, it receives a text stream representing the object, and does not integrate with the PowerShell type system.

The PowerShell Extended Type System (ETS) is based on the .NET type system, but with extended semantics (e.g. propertySets and 3rd 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.

Cmdlets are specialized commands in the PowerShell environment that implement specific functions. These are the native commands similat to set of Unix utilities.

Cmdlets follow a <verb>-<noun> naming pattern, such as Get-ChildItem. Cmdlets output their results as objects, or 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.

Cmdlets are specialized .NET classes, which the PowerShell runtime instantiates and invokes when they are run. Cmdlets derive either from Cmdlet or from PSCmdlet, the latter being used when the cmdlet needs to interact with the PowerShell runtime.[19] These base classes specify certain methods - BeginProcessing(), ProcessRecord() and EndProcessing() - one of which the cmdlet's implementation overrides to provide the functionality. Whenever a cmdlet is run, these methods are invoked by PowerShell in sequence, with ProcessRecord() being called if it receives pipeline input.[20] 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.

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[21] 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.[22]

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.[23] 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.

In PowerShell V2, a more portable version of Cmdlets called Modules have been added. 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 self-contained 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."

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, as well as integration with .NET. Variables in PowerShell scripts have names that start with $; they can be assigned any value, including the output of cmdlets. While the language is untyped, internally the variables are stored with their types, which can be either primitive types or objects. 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. According to the variable syntax, if the path to a file is enclosed in braces preceded by a dollar sign (as in ${C:\foo.txt}), it refers 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, it will be read from the file. If an object is assigned, it is serialized before storing it.

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.[25] 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.

Using the function keyword, PowerShell provides for the creation of functions, which can take parameters. A common problem for people new to PowerShell is that function arguments are separated by spaces, not commas:

  1. <function> <param1> <param2>: Calls the function with two arguments. (These arguments may be bound to parameters declared in the function definition or accessed by position from the $args array.)
  2. <function>(<param1>, <param2>): Calls the function with a single argument, a two element array.

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.[26] 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.[26]

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 trap keyword. However, the action-or-error is configurable; in case of an error, PowerShell can be configured to silently resume execution, without trapping the exception.[27]

Scripts written using PowerShell can be made to persist across sessions in a .ps1 file. Later, either the entire script or individual functions in the script can be used. Scripts and functions are used 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. However, script execution is disabled by default and must be enabled explicitly.[28] PowerShell scripts can be signed to verify their integrity, and are subject to Code Access Security.

The PowerShell scripting language supports binary prefix notation similar to the scientific notation supported by many programming languages in the C-family.

Another use of PowerShell is being embedded in a management application, which then 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.[3] 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.

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.[3] 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 an InputPipe, Outputpipe and ErrorOutputPipe objects, to represent the connection with the pipeline. The types are verified and parameters bound using reflection.[3] 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 it itself.

The hosting APIs are used by Microsoft Exchange Server 2007 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.

Comparison of cmdlets with similar commands

The following table contains a selection of the cmdlets that ship with PowerShell noting the most similar commands in other well known command line interpreters.

Windows PowerShell
Windows PowerShell
cmd.exe / COMMAND.COM
(MS-DOS, Windows, OS/2, etc.)
(Unix, BSD, Linux, Mac OS X etc.)
Get-ChildItem gci, dir, ls dir ls List all files / directories in the (current) directory
Get-Content gc, type, cat type cat Get the content of a file
Get-Command gcm help which List available commands
Get-Help help, man help man Help on commands
Clear-Host cls, clear cls clear Clear the screen[Note 1]
Copy-Item cpi, copy, cp copy cp Copy one or several files / a whole directory tree
Move-Item mi, move, mv move mv Move a file / a directory to a new location
Remove-Item ri, del, erase, rmdir, rd, rm del, erase, rmdir, rd rm, rmdir Delete a file / a directory
Rename-Item rni, ren, mv ren, rename mv Rename a file / a directory
Get-Location gl, pwd cd pwd Display the current directory/present working directory.
Pop-Location popd popd popd Change the current directory to the directory most recently pushed onto the stack
Push-Location pushd pushd pushd Push the current directory onto the stack
Set-Location sl, cd, chdir cd, chdir cd Change the current directory
Tee-Object tee n/a tee Pipe input to a file or variable, then pass the input along the pipeline
Write-Output echo, write echo echo Print strings, variables etc. to standard output
Get-Process gps, ps tlist,[Note 2] tasklist[Note 3] ps List all currently running processes
Stop-Process spps, kill kill,[Note 2] taskkill[Note 3] kill[Note 4] Stop a running process
Select-String n/a find, findstr grep Print lines matching a pattern
Set-Variable sv, set set set Set the value of a variable / create a variable

  1. ^ Clear-Host is implemented as a predefined PowerShell function.
  2. ^ a b Available in Windows NT4, Windows 98 Resource Kit, Windows 2000 Support Tools
  3. ^ a b Available in Windows XP Professional Edition and later
  4. ^ Also used in UNIX to send a process any signal, the "Terminate" signal is merely the default


Examples are provided first using the long-form canonical syntax and then using more terse UNIX-like and DOS-like aliases that are set up in the default configuration.

 PS> get-process p* | stop-process
 PS> ps p* | kill
 PS> get-process | where-object { $_.WS -gt 1000MB } | stop-process
 PS> ps | ? { $_.WS -gt 1000MB } | kill
 PS> get-childitem | measure-object -property length -sum
 PS> ls  | measure length -s
 PS> dir | measure length -s
 PS> $processToWatch = get-process notepad
 PS> $processToWatch.WaitForExit()
 PS> (ps notepad).WaitForExit()
 PS> 'hello, world!'.ToUpper()
 PS> 'string'.Insert(1, 'ABC')
PS> $rssUrl = ''
PS> $blog = [xml](new-object System.Net.WebClient).DownloadString($rssUrl)
PS> $ | select title -first 8
$x=new-object xml;$x.load('');$|select title -f 8
 PS> $UserProfile = $env:UserProfile
PS> [System.Windows.Forms.MessageBox]::Show('Hello, World!')
PS> [Array]$arguments = '-h', '15', ''
PS> tracert $arguments

File extensions

Featured Webcast Series

Windows PowerShell Essentials for the Busy Admin Series

In this series, Microsoft Scripting Guy Ed Wilson discusses a number of compelling reasons for learning Windows PowerShell scripting and provides training for some of the most important Windows PowerShell uses for IT admins.

More Windows PowerShell Scripting Webcasts

Learn the basics of Windows PowerShell from Microsoft Scripting Guy Ed Wilson. In this five-part webcast series, Ed demonstrates starting and stopping processes and services, working with event logs, writing your first Windows PowerShell script, working with files, and more.

Hey, Scripting Guy! Blog RSS

Seven days each week, Scripting Guy Ed Wilson answers your questions about Windows PowerShell. Learning this stuff could be daunting. Ed makes sure it's not.

Windows PowerShell Scripting

More Windows PowerShell Blog Posts >

Hey, Scripting Guy! Getting Started posts
Use the Getting Started tag on the blog so you can easily find Windows PowerShell content intended for beginners.


Top Visited
Past week
Past month


Old News ;-)

[Jun 08, 2021] PowerShell For Beginners Full Course - PowerShell Beginner tutorial Full Course

YouTube video
Apr 21, 2021 |

Windows PowerShell [01] Introduction - YouTube

[May 28, 2021] Powershell Video Tutorials "" CodingBee

May 24, 2021 |

Powershell Video Tutorials

The following courses are available at Pluralsight. You can sign up for a 10 day free trial!

Announcement You can find all my latest posts on medium .

PowerShell Remoting Fundamentals

PowerShell Toolmaking Fundamentals

Building PowerShell GUIs in WPF for Free

Working with CSV Data in PowerShell

Your First Day with PowerShell

PowerShell: Getting Started

Putting PowerShell to Work

PowerShell on the Network

What's New in PowerShell v5.0

PowerShell Cmdlet Development in C# "" The Ins and Outs

Reporting with PowerShell HTML and Enhanced HTML

Accessing SQL Server Databases from PowerShell

Debugging PowerShell in VS Code

Working with XML Data in PowerShell

Windows Server Administration Fundamentals Using PowerShell

PowerShell and SQL Server

Play by Play: Microsoft Open Source PowerShell on Linux and Mac

Client-Side PowerShell Scripting for Reliable SCCM Deployments

Creating GUIs Using PowerShell Studio 2015 "" The Essentials

PowerShell & DevOps Global Summit 2016 Sessions

Beginning PowerShell Scripting for Developers

Windows Workflows with PowerShell

Managing Azure IaaS with PowerShell

Implementing Microsoft PowerShell Just Enough Administration (JEA)

Using WMI and CIM in PowerShell

Windows PowerShell Desired State Configuration Fundamentals

Advanced Windows PowerShell Desired State Configuration

Managing DHCP With PowerShell

Administering Active Directory Objects with PowerShell

[Apr 22, 2021] PowerShell For Beginners Full Course - PowerShell Beginner tutorial Full Course - YouTube

Apr 22, 2021 |

Windows PowerShell [01] Introduction - YouTube

[Jan 12, 2020] How to create and run a PowerShell script file on Windows 10 Windows Central

Jan 12, 2020 |

Are you new to PowerShell? Use this guide to create and run your first script file on Windows 10. Mauro Huculak 9 Oct 2019 8 <img src="" width="800" height="600" alt="">

On Windows 10, PowerShell is a command-line tool that allows you to run commands and scripts to change system settings and automate tasks. It's similar to Command Prompt. Still, PowerShell is a more capable command-line interface (CLI) that provides an extensive set of tools and offers more flexibility and control (especially for scripting).

A script is just a collection of commands saved into a text file (using the .ps1 extension) that PowerShell can understand and execute in sequence to perform one or multiple actions. The only caveat is that unlike Command Prompt, the default security protocol always prevents all scripts from running on your device.

This means that when double-clicking a ".ps1" file on Windows 10 nothing will happen, and if you try to execute the script within PowerShell, you'll get the "cannot be loaded because running scripts is disabled on this system" error message. However, it's not impossible to run scripts. You just need to enable the correct execution policy.

Our favorite VPN service is more affordable now than ever before

In this Windows 10 guide , we walk you through the steps to successfully run your first script file on PowerShell.

How to create a PowerShell script file on Windows 10

On Windows 10, you can create PowerShell script files using virtually any text editor or the Integrated Scripting Environment (ISE) console that comes preinstalled on every installation.

Creating a script using Notepad

To create a PowerShell script using Notepad on Windows 10, use these steps:

  1. Open Start .
  2. Search for Notepad , and click the top result to open the app.
  3. Write a new or paste your script on the text file -- for example:

    Write-Host "Congratulations! Your first script executed successfully"

    <img src="" width="800" height="454" alt="">

    The above script will output the phrase "Congratulations! Your first script executed successfully" on the screen.

  4. Click the File menu.
  5. Select the Save as option.
  6. Type a name for the script -- for example, first_script.ps1 .

    <img src="" width="800" height="454" alt="">

  7. Click the Save button.
Creating a script using Integrated Scripting Environment

Alternatively, you can use the built-in PowerShell ISE console to code your scripts on Windows 10.

The Integrated Scripting Environment is a complex tool, but you can get started using these steps:

  1. Open Start .
  2. Search for Windows PowerShell ISE , right-click the top result, and select the Run as administrator option.
  3. Click on File .
  4. Select the New option to create a new empty .ps1 file.

    <img src="" width="800" height="503" alt="">

  5. Write a new or paste the script you want to run -- for example:

    Write-Host "Congratulations! Your first script executed successfully"

    <img src="" width="800" height="470" alt="">

  6. Click the File menu.
  7. Click the Save option.
  8. Type a name for the script. For example, first_script.ps1 .

    <img src="" width="800" height="502" alt="">

  9. Click the Save button.

Once you complete the steps using Notepad or PowerShell ISE, the script is ready to run, but it will fail by default. This is because the default PowerShell settings are always set to block the execution of any script.

How to run a PowerShell script file on Windows 10

If you want to run a script file on PowerShell, you have to change the execution policy on Windows 10.

To change the execution policy to run PowerShell scripts, use these steps:

  1. Open Start .
  2. Search for PowerShell , right-click the top-result and click the Run as administrator option.
  3. Type the following command to allow scripts to run and press Enter :

    Set-ExecutionPolicy RemoteSigned

  4. Type A and press Enter (if applicable).

    <img src="" width="800" height="367" alt="">

  5. Type the following command to run the script and press Enter :

    & "C:\PATH\TO\SCRIPT\first_script.ps1"

    <img src="" width="800" height="348" alt="">

    In the above command, make sure to change "PATH\TO\SCRIPT" to the location of your script.

After you complete the steps, the script will run, and if it was crafted correctly, you should see its output without issues.

On Windows 10, PowerShell includes four execution policies, including:

In the above steps, we use the command to allow local scripts to run on Windows 10. However, if you're not planning to execute scripts regularly, you can restore the default settings to prevent running scripts that you don't trust using the same instructions, but on step No. 4 , make sure to use the Set-ExecutionPolicy Restricted command.

More Windows 10 resources

For more helpful articles, coverage, and answers to common questions about Windows 10, visit the following resources:

[Nov 17, 2017] The Windows PowerShell Debugger

Nov 17, 2017 |
The Windows PowerShell Debugger The information in this article was written against the Community Technology Preview (CTP) of Windows PowerShell 2.0. This information is subject to change in future releases of Windows PowerShell 2.0.

The PowerShell Debugger Setting Breakpoints Responding to Breakpoints Listing Breakpoints Enabling and Disabling Breakpoints Removing Breakpoints

The PowerShell Debugger

In Windows PowerShell 2.0 (the November 2007 Community Technology Preview release) the PowerShell team has taken an interesting approach to script debugging. As you know, PowerShell doesn't require a specialized script editor or development environment. Instead, PowerShell users can, and do, use any and all text editors (from Notepad on up) to write their scripts. Because of that, the PowerShell team decided to build their debugging tools into Windows PowerShell itself; in turn, that means that you can use the new debugging cmdlets to debug any script from the console window itself.

Pretty cool, huh?

But don't just take our word for that; let's show you how some of these cmdlets work. In particular, let's take a brief look at the following new PowerShell 2.0 cmdlets:

Top of page Setting Breakpoints

Windows PowerShell's new debugging features are built around the notion of "breakpoints." A breakpoint is simply a designated spot in a script where you would like execution to pause. For example, suppose you have a script that copies a file from one location to another, and then deletes the original file. (OK, admittedly, you'd be better off writing a script that simply moved the file, but that wouldn't help us make our point.) Let's further suppose that your script looks like this:

Write-Host "Copying folder."
Copy-Item D:\Logfiles -destination D:\Backup
Write-Host "Deleting folder."
Remove-Item D:\Logfiles

As you might expect, this script hinges on one key line of code: the line where the Copy-Item cmdlet copies the folder D:\Logfiles to D:\Backup. What makes this line so crucial? Well, suppose this line fails but the script continues to run. Let's further suppose that the last line of code, the one where the Remove-Item cmdlet deletes the original folder, succeeds. What would that mean? That would mean that the script failed to copy D:\Logfiles to the backup location, but succeeded in deleting D:\Logfiles (even though no backup copy exists). And that would mean that the folder D:\Logfiles, and everything in it, would be gone without a trace.

Probably not what you had in mind.

So what can you do about that? How can you test this script risk-free, or at least as close to risk-free as you can get?

Well, one thing you can do is set a breakpoint on line 4 (Write-Host "Deleting folder.").That enables you to run the script and execute lines 1, 2, and 3. When you get to line 4, however, the script will pause and wait for further instructions. (What kind of instructions? We'll discuss that in a minute.) That, in turn, gives you a chance to verify that D:\Logfiles has been successfully copied to D:\Backup. If it has then you can continue to run the script. If it hasn't, then you can type {break} to stop execution of the script before the folder is deleted. And once the script has successfully – and safely – been stopped, you can begin debugging lines 1 through 3 to try and determine why the folder didn't get copied over.

That sounds pretty handy, doesn't it? OK, so then how do you set a breakpoint on line 4? Why, by doing this, of course:

New-PSBreakpoint -script C:\Scripts\Test.ps1 -line 4

That was easy, wasn't it? As you can see, all we had to do was call the New-PSBreakpoint cmdlet, passing New-PSBreakpoint two parameters:

So what happens now? Well, now we simply run the script; when the script reaches line 4 it will pause and prompt us for further instructions. That scenario will play out something similar to this:

Copying folder.
DEBUG: Hit breakpoint(s) on 'C:\Scripts\Test.ps1:4'
DEBUG:  Line breakpoint on 'C:\Scripts\Test.ps1:4'
PS C:\scripts>>>{break}
PS C:\scripts>

Notice at the prompt that we typed {break} to terminate the script.

Important . As you might know (but probably didn't), breakpoints are tied to the current PowerShell session and not to the script. That means that any breakpoints you set will disappear as soon as you exit PowerShell. Keep in mind, too, that the breakpoints work only in the PowerShell session where they were set. Suppose you create a new breakpoint in one PowerShell session and then open a second PowerShell session. That breakpoint will not be available in the second PowerShell session, you'll need to reset any breakpoints you want in this second session.

Admittedly, setting a breakpoint on line 4 was pretty cool. But you ain't seen nothin' yet. Sure, it's easy to set a breakpoint on a particular line in a script. (And yes, you can set as many breakpoints on a script as you want. On top of that, you can set breakpoints on as many different scripts as you want.) But PowerShell doesn't limit you to setting breakpoints only on lines. Instead, you can also set breakpoints on such things as:

Variables . When you set a breakpoint on a variable the script will (by default) pause any time the value of that variable changes. To set a breakpoint on a variable, simply use the –variables parameter followed by the name (or names) of the variable of interest. (Just make sure to leave the $ off when specifying the variable name.) For example, this command sets a breakpoint on the variable $a:

New-PSBreakpoint -script C:\Scripts\Test.ps1 -variables a

As we noted, by default breakpoints are triggered any time the value of a variable changes ( WriteMode ). Alternatively, you could have a breakpoint triggered any time a variable value is read ( Read ); this includes each and every time that the value of this variable is displayed onscreen or used in a calculation. Or, set the breakpoint to ReadWriteMode and have the breakpoint triggered any time the variable is referenced.

Oh, good question. Here's how you set the mode for a variable breakpoint:

New-PSBreakpoint -script C:\Scripts\Test.ps1 -variables a -Read

Commands . You can also set a breakpoint any time a particular command is used in a script. For example, the following command sets a breakpoint on the Get-Content command:

New-PSBreakpoint -script C:\Scripts\Test.ps1 -commands "Get-Content"

You c an even get more specific than that. For example, this command sets a breakpoint on Get-Content, but only when the cmdlet is used to open the file C:\Scripts\Test.txt:

New-PSBreakpoint -script C:\Scripts\Test.ps1 -commands "Get-Content C:\Scripts\Test.txt"

Functions . Set a breakpoint any time a function is called? Hey, why not? Here's a command that sets a breakpoint any time the function ConvertDate is called:

New-PSBreakpoint -script C:\Scripts\Test.ps1 -function ConvertDate

Before we move on, here's one last note about the New-PSBreakpoint cmdlet. By default, the script simply pauses and waits for further instructions any time it encounters a breakpoint. If you want to, however, you can execute a specific command (or set of commands) when a breakpoint is encountered. To do that, simply add the –action parameter followed by the command or commands to be run. (Technically these commands need to be passed as a script block, which means they must be enclosed in curly braces.) For example, this command displays the value of the variable $a any time the specified breakpoint is triggered:

New-PSBreakpoint -script C:\Scripts\Test.ps1 -variables a -action {Write-Host $a}

One action you might want to specify is this: {break} . This will automatically terminate the script when a breakpoint is reached.

Top of page Responding to Breakpoints

Unless you use the –action parameter, any time you a hit a breakpoint the script will pause and present you with a nested command prompt. When that happens, PowerShell will simply sit patiently and wait for you to tell it what to do.

That's great, except for one thing: what exactly can you tell it to do? To be honest, you can tell it pretty much anything you want to tell it. As we've already seen, you can simply type the keyword {break} and press ENTER; that will cause the script to terminate. Alternatively, you might want to run a full-fledged PowerShell command. For example, suppose your script is supposed to create a text file named C:\Scripts\Test.txt and then hit a breakpoint. At that point, you could use the Get-Content cmdlet to read the contents of that file:

Get-Content C:\Scripts\Test.txt

That's pretty cool. However, more often than not you'll end up executing one of the following new cmdlets any time you encounter a breakpoint:

Step-Into . The Step-Into cmdlet enables you to execute the next line of code in the script. Just type Step-Into at the command prompt and press ENTER; in response, PowerShell will execute the next line of code. At that point the script will stop and wait for further instructions, even if no breakpoint has been set on that particular line of code.

In other words, Step-Into allows you to run a script line-by-line.

Step-Out . When you call the Step-Out cmdlet your script will begin to run again, not stopping until it reaches the next breakpoint (or until it runs out of lines to execute). Unlike Step-Into, Step-Out does not run a script line-by-line. Instead, it runs until it reaches a breakpoint; pauses; runs until it reaches the next breakpoint; pauses; then – well, you get the idea.

To use this cmdlet, type Step-Out at the command prompt and then press ENTER; in response, PowerShell will execute the next line of code, and then continue to execute lines of code, without stopping, until the next breakpoint is encountered.

Important note. If you are inside a function when you call the Step-Out cmdlet, the debugger will exit the function and step to the statement immediately following the function call; from there the script will continue to run until the next breakpoint is encountered.

What does that mean? Well, suppose we are halfway through function A when we call Step-Out. Let's further suppose that there are no more breakpoints in the script. In a case like that, the debugger will exit the function (without running any additional lines of code in that function), and then – because there are no more breakpoints –will run the rest of the script. What if there was another breakpoint? Then the script would stop at that breakpoint and await further instructions.

Step-Over . The Step-Over cmdlet is roughly similar to Step-Into: it's designed to execute code line-by-line. However, there is an exception or two. (Which there should be; otherwise Step-Over would be Step-Into.) If the next line of code to be executed happens to be a function call, Step-Over will, well, "step over" that call. What does that mean? That means that Step-Over will execute the entire function without stopping; you will not step into the individual lines of code within that function. For example, suppose we hit a breakpoint at this point in a script:

Set-Location C:\Scripts

If we use the Step-Over cmdlet with these lines of code, the script will run line 1, the line that calls the Set-Location cmdlet, and then pause. If we use the Step-Over cmdlet again, the script will then run line 2, which calls a function named ConvertDate. At that point, all the lines of code within the Convert-Date function will execute, without stopping. The script will not pause until after the function has finished executing. If we call Step-Over a third time the script will then "step into" line 3, meaning it will pause on this line and await further instructions.

By the way, you can use any or all of these cmdlets during a single debugging session. That enables you to, say, step through a particular section line-by-line, and then step over or step out of the next section in the script.

Top of page Listing Breakpoints

On the one hand, it's pretty cool to have breakpoints tied to the PowerShell environment rather than an individual script; on the other hand, that makes it harder to figure out which breakpoints, if any, have been placed on a script. (Why? Because you can't just open up the script in a script editor or debugger and view the breakpoints.)That's where the Get-PSBreakpoint cmdlet comes in. Called without any additional parameters Get-PSBreakpoint returns information similar to the following for all the breakpoints in the current PowerShell session:


Do that and you'll get back information similar to this for each breakpoint set during the current session:

Function: ConvertDate
Enabled: True
HitCount: 1
Id: 0
Script: C:\Scripts
ScriptName: C:\Scripts\Test.ps1
Alternatively, you can specify a breakpoint ID and get back information only for the specified breakpoint:
Get-PSBreakpoint -ID 7

The –id parameter is the only parameter available to Get-PSBreakpoint. However, by piping the information retrieved by Get-PSBreakpoint to the Where-Object cmdlet you can retrieve a collection of breakpoints that fit some other criteria. For example, this command retrieves all the breakpoints associated with the script C:\Scripts\Test.ps1:

Get-PSBreakpoint | Where-Object (ScriptName - eq "C:\Scripts\Test.ps1")

      Enabling and Disabling Breakpoints 

By using the Enable-PSBreakpoint and Disable-PSBreakpoint cmdlets you can selectively enable and disable breakpoints during a Windows PowerShell session. To disable a breakpoint all you need to do is call the Disable-PSBreakpoint cmdlet, specifying the ID of the breakpoint to be disabled:

Disable-PSBreakpoint -ID 7

To enable that particular breakpoint, just use the Enable-Breakpoint cmdlet:

Enable-PSBreakpoint -ID 7

To disable (or enable) all the breakpoints in a PowerShell session, use Get-PSBreakpoint to retrieve a collection of breakpoints 
      and then pipe that collection to the appropriate cmdlet. For example, this command disables all the breakpoints in the current 
Get-PSBreakpoint | Disable-PSBreakpoint

Or, again, use a command like this to disable all the breakpoints associated with the script C:\Scripts\Test.ps1:
(Get-PSBreakpoint | Where-Object (ScriptName - eq "C:\Scripts\Test.ps1"))
| Disable-PSBreakpoint

      Removing Breakpoints 

As an alternative to disabling a breakpoint you can simply delete that breakpoint. Want to delete the breakpoint with the ID 7? Then simply call the Remove-PSBreakpoint cmdlet, specifying the breakpoint to be removed:

Remove-PSBreakpoint -ID 7

To delete all the breakpoints in the current PowerShell session us Get-PSBreakpoint to retrieve a collection of breakpoints and then pipe that collection to the Remove-PSBreakpoint cmdlet:

Get-PSBreakpoint | Remove-PSBreakpoint

And this command – oh, you guessed it. Yes, this command does remove all the breakpoints associated with the script C:\Scripts\Test.ps1:

(Get-PSBreakpoint | Where-Object (ScriptName - eq "C:\Scripts\Test.ps1"))
| Removeakpoint

[Sep 05, 2014] Slashdot discussion

Re:Powershell (Score:4, Interesting)

by asmkm22 (1902712) writes: on Friday September 05, 2014 @01:31PM (#47835949)

A lot of bash and *nix stuff is in PowerShell, which I think it's the point. I remember the first time I opened a session and instinctively typed "ls" without it giving an error.

Re: (Score:2)

by i kan reed (749298) writes:

And bash having it is precisely why powershell has it. They wanted to capture every bash user as instantly friendly for neo-dos, and stole as many nix commands as they could. I haven't actually tried, but I have this suspicion that a fair number of bash scripts would just work in powershell.

Re: (Score:2, Informative)

by Anonymous Coward writes:

I would suspect that none of them would work. While PowerShell did borrow a lot of syntax from shell batch languages and dynamic languages it is quite dissimilar to both.

Re:Powershell (Score:4, Informative)

by MightyMartian (840721) writes: on Friday September 05, 2014 @01:19PM (#47835825) Journal

Powershell is just enough like Bash to make me groan after ten minutes and ask "Why the f--- didn't they just make an integrated Bash shell?"

Re:Powershell (Score:5, Funny)

by lister king of smeg (2481612) writes: on Friday September 05, 2014 @01:42PM (#47836077)

Powershell is just enough like Bash to make me groan after ten minutes and ask "Why the f--- didn't they just make an integrated Bash shell?"

Powershell - the ugly the bastard child of Bash and Batch.

Re:Powershell (Score:5, Insightful)

by nine-times (778537) writes: <[email protected]> on Friday September 05, 2014 @04:36PM (#47837477) Homepage

You know, I kind of hated Powershell until I was forced to use it.

I still hate it. But then I have to write a bash script, and I run across some specific problem while writing a bash script, and find myself thinking, "This would be easier in Powershell." So that's something.

It's really not like Batch files, though. It really isn't that bad of a scripting language.

Re:Powershell (Score:5, Interesting)

by Bacon Bits (926911) writes: on Friday September 05, 2014 @02:27PM (#47836461)

Two reasons:

1. POSIX environments have already been done on Windows, and they universally suck. SFU/Interix is shit. Cygwin is shit. MKS Toolkit is shit. MinGW/MSYS, which does a better job than any of them, is mostly shit. Even UnxUtils, which is just binaries modified for use with the actual Windows cmd shell are mostly shit. There are so many fundamental differences of philosophy that make working with a Windows system as though it were a POSIX system fundamentally untenable. You're stuck with mostly just munging text files in a binary world.

2. Powershell is what .NET developers think Windows administrators want in a shell. That's why you're allowed to do stuff like import .NET assemblies and use essentially unmodified C# code, but there's still no native SFTP client or server.

Powershell is about 90% of what an administrator actually wants in a shell, and it's actually not that bad. Compared to cmd.exe or VBscript it's balls out fantastic. However, an administrator shouldn't need to learn about .NET objects to be able to write a script, and they shouldn't feel like there's such a fundamental separation between what the shell can do with .NET piping and what executable programs can do. There's a very real encouragement to make everything in Powershell written in and with Powershell exclusively. Like no calling of a binary to do something unless you have no other choice. The shell and the community philosophy very much discourage that... for no real reason other than it's more difficult to get a .NET object out of a binary file and manipulate it with arbitrary .NET methods. I've seen people re-implement a command line zip program with [System.IO.Compression] instead of just using 7z.exe. Why? Just so they can use .NET objects that they never do anything with.

Honestly I really love Powershell, but I wish the philosophy were geared more around getting shit done than getting shit done with .NET.

Re:Powershell (Score:4, Interesting)

by MightyMartian (840721) writes: on Friday September 05, 2014 @04:57PM (#47837663) Journal

Apart from anything else, what I truly dislike about Powershell is how verbose it is. Perhaps it's my *nix heritage, but I like tidy little mnemonic commands like "mv", "rm" or "grep". Less typing, less things to wrong when you're writing scripts. I also find the syntax rather awkward. It's far better than the alternatives (like vbscript or jscript with WMI), but it's still a long ways away from what I would consider a decent scripting language.

Actually, the worst part of about Powershell is how awfully slow it is. I'm sure that is because it's basically an interface sitting on top of .NET. The *nix shells are, for the most part, self-contained binaries, so bringing up a Bash script is very fast. But then again, sh and its descendants aren't trying to create a "do it all" environment, but rather create control structures and variables to expand upon existing *nix commands.

I wrote a Powershell scriptlet a few months ago to dump Exchange 2010 mailboxes based on some criteria. Works like a charm, and like I said, despite my dislike of Powershell itself, I'm very grateful that it exists. But loading the Exchange scriptlets library takes something 10 to 20 seconds, and you can see Powershell nailing system resources like crazy to get to that point.

While its roots, or at least its inspiration, are the Unix shells, in very important ways, it ignores key Unix principles. It is indeed what Bash would work like if it had been written by Microsoft.

Re: (Score:3)

by Darinbob (1142669) writes:

I thought 'test' in Bash is built in, whereas in older shells it relied on the Unix command 'test'.

Re:a fucking slideshow? (Score:5, Insightful)

by Anrego (830717) * writes: on Friday September 05, 2014 @12:30PM (#47835307)

I don't even bother with infoworld links any more. It'll be a bunch of slides with a sentence of text, an unrelated image, and ads everywhere (ads on the slides, ads before the slides, an add in the middle of the slideshow, and an ad at the end). Content wise, usually they find one or two interesting things, then fill the rest of the slots with stupid shit everyone already knows.

Mar 23, 2011] The Great Dollar Dollar - Windows PowerShell Blog - Site Home - MSDN Blogs

Contains the last token in the last line received by the session.


The '$$' ("dollar dollar") automatic variable always holds the last thing on the last line you typed. Now, why would you ever care about tokens received by the session? It saves you typing, that's why!

PS>notepad $$

Voila – notepad opens 'c:\windows\system32\drivers\etc\hosts'.

If you're a shell polyglot, the Bash shell (in Unix, Mac, etc.) supports something similar through its '!$' word designator.

[Mar 23, 2011] Does Your Hard Work Advance the Ecosystem - Windows PowerShell Blog - Site Home - MSDN Blogs

Feb 6, 2011

The Lync PowerShell Blog recently posted a fairly chewy piece that described how to enable users in bulk when given an XLS file as input.

Jason Helmick responded, saying:

Instead of your incredible code that no admin would even begin to understand or even be able to write, let's do the same thing, in one line. (Note: This is an educated PowerShell admin, or any typical Unix guy.)

Step 1: Admin receives xls from HR. They then proceed to use Excel to convert it to CSV. Total time, 10 seconds.

Step 2: They then type the following one-liner:

Import-CSV C:\Scripts\NewUsers.csv | %{Enable-CsUser -Identity $_.Name -RegistrarPool $_.RegistrarPool -SipAddress $_.SipAddress}

[Mar 17, 2010] Power Shell Usage Bash Tips & Tricks

Searching the Past

Yes, PowerShell (Score:5, Informative)

by benjymouse (756774) on Thursday March 05, @03:22PM (#27081843)

Available from Microsoft for XP, 2003; included in Server 2008 and Windows 7.

The name is really lame, but it *is* damn powerful. At least for Windows which has most of it API exposed through object-oriented technologies (COM, .NET and WMI) which are easily used in a unified way by PowerShell.

Just a few quick samples:

Command substitution a "new idea?" (Score:3, Informative)

by dpbsmith (263124) on Thursday March 05, @10:19PM (#27086913) Homepage

"Command substitution was something else I added because that gives you very general mechanism to do string processing; it allows you to get strings back from commands and use them as the text of the script as if you had typed it directly. I think this was a new idea that I, at least, had not seen in scripting languages, except perhaps LISP,' he says."

Surely this feature was present in Calvin Mooer's TRAC [], circa 1964 or thereabouts. I've forgotten the distinction between expanded macros by means of single or double slashes, but I believe one or the other of them substituted the macro expansion back in the stream for further processing. My recollection is that it was fundamental to the way TRAC was used in practice. My recollection is also that TRAC was moderately well-known in the community at the time, so the idea was "in the air."

I believe it also existed in a host of "macro" capabilities in assembly languages... familiar to me in MIDAS, an assembly language for the PDP-1 circa 1965 or so. MIDAS survived into the PDP-6 and PDP-10, may have been developed earlier for the TX-0, and I think may have been patterned on advanced macro assemblers for the IBM 709.


The Great Big Messy Book is back in print []

My /bin/sh rules (Score:3, Informative)

by SpaghettiPattern (609814) on Friday March 06, @12:38AM (#27087761)

As an IT pro, I recognize the significance of /bin/sh and I am very grateful for to Steve Bourne for his creation. It's the smallest (that's a good thing), consistent and standardized command set for setting up environments to run programs.

My scripting rules on UNIX like systems:

owerShell and critique of the Unix shell (Score:5, Insightful)

by Tetsujin (103070) on Thursday March 05, @05:04PM (#27083343) Homepage

so users can express themselves using the same basic style as they'd use in a Unix shell, but working with a more powerful set of libraries and data types.

Like a Unix user would be calling Perl or Python?

Not quite... The shell user can call Perl or Python to access libraries or datatypes -- but these concepts are meaningless within the framework of the shell itself. In Powershell, a commandlet returning an object yields something you can work with in the shell - see what object methods or data fields it provides, run methods, pass the object to another commandlet, etc.

Powershell provides a powerful set of baseline assumptions for the format of data over the pipe - and so both the shell itself and commandlets running in the shell can take advantage of these assumptions. In Unix, the typical approach is to "roll your own format" each time - which is trivial for trivial problems, but substantially harder as you start worrying about questions like, what happens when my data fields contain the character I want to use as a delimiter?

This is further complicated by the fact that existing Unix programs, outputting text, typically format that text for human consumption. The exact format of a program's input or output may change from release to release with no coherent strategy for establishing any kind of compatibility. In comparison, in Powershell a piece of data passed from one process to another has a predictable underlying structure - it's formatted for consumption by another process rather than for display at the terminal. But since the shell itself also recognizes this format, it has a reasonable default behavior for displaying a command output - or if necessary you can pipe through a command whose job is to make nicely formatted output of selected columns of another program's result.

Now, what are the benefits of serializing to text format? You can look at it, printed on-screen, and know what it represents and how to parse it, right? The problem is this becomes less and less true as the data format becomes more intricate, more comprehensive - which is bound to happen as you start doing things like handling more complex problems, implementing data formats that account for future upgrades, and so on. The strength of PowerShell's approach (the same approach, basically, as you'd find in any other capable, interactive programming language) is that it knows enough about the format of data it handles that it can make that format easy to view and work with - easier, in fact, than plain text, because you see a representation of the data's meaning rather than of its underlying structure.

As another example, consider what it would take to provide any kind of higher-order programming in the shell. There's a limited degree of this available already, of course: if you want to pass a "function" to something, you form it into a shell script, put it in a directory somewhere, and provide the full pathname to that function as an argument to your higher-order program - which will then use something like "system()", "popen()" or "exec()" to invoke it.

Now, what if you want to include a set of data, representing the state of an "object" with that "function"? You can do that, too - you can write out a data file representing the current state, and pass both the script and the data file names to your higher-order program. Or you could have a program running in the background, communicating via some form of IPC - maybe over a named pipe or listening to a particular network socket or hosted by an object broker, and pass the necessary reference to the higher-order function. Or, about the nicest you can manage in the shell (though decidedly not a clean solution IMO) - start a process in the background which maintains the state you're working with, and have a second executable which communicates with the background process, passing on commands and bringing back results.

The problem is, none of those me

Here in my car -- I make analogies
It is handy because -- you can relate to them
In cars...

Read the rest of this comment...

Re:PowerShell (Score:5, Insightful)

by Tetsujin (103070) on Thursday March 05, @02:33PM (#27081225) Homepage

Welcome to 1975, Microsoft.

Meh, give Powershell some credit. It exposes a lot more functionality with a lot better organization than a Unix shell would. They took the basic paradigm of the shell and made it fit the .NET environment - so users can express themselves using the same basic style as they'd use in a Unix shell, but working with a more powerful set of libraries and data types. I think it's significant, and I think the Unix world could learn a thing or two from it, about keeping what's good about the shell, but moving the basic technology out of the 1970s.

Re:Greenspun's Tenth Rule (Score:4, Insightful)

by RAMMS+EIN (578166) on Thursday March 05, @01:30PM (#27080277) Homepage Journal

The parent comment was modded funny, but I think Greenspun's Tenth is still relevant today. And, applied to Unix, it's definitely true. Imagine what Unix would be like if there only were C. But there isn't only C, there is also the shell and various scripting languages. The shell's most important feature is that it's interactive, like Lisp's read-eval-print loop. Todays popular scripting languages on Unix (say, Perl and Python) implement many of the other features of Lisp, allowing programs to be expressed a lot more succinctly and conveniently than in C. But all these are part of the same universe: the shell works mostly by running other programs, and the scripting languages do some of their tasks by going through the shell or C libraries. So, with everything together, you end up with something vaguely like what Lisp offers in a single package.

Of course, the world hasn't stood still, and the Unix universe now offers many features that aren't really present, or at least not standardized, in the Lisp universe.

And, in the meantime, Java has come along, re-inventing and re-implementing tons of features from Lisp and Unix.

Re:Greenspun's Tenth Rule (Score:5, Funny)

by Hatta (162192) on Thursday March 05, @02:33PM (#27081239) Journal

Greenspun's Tenth Rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp"

As a corollary, we can see that any C or Fortran program that does not contain an ad hoc, informally-specified, bug-ridden slow implementation of half of Common Lisp is insufficiently complicated.

Censorship is obscene.
Patriotism is bigotry.
Slashdot 2.0 sucks.

The Unix Shell and Scripting Languages (Score:4, Interesting)

by Tetsujin (103070) on Thursday March 05, @03:11PM (#27081701) Homepage

Backticks? Why on earth would you use backticks to move files around? That's what File::Copy is for. And Archive::Tar handles tarballs.

Write Perl code, not shell scripts wrapped in Perl code.

All of this raises an issue that interests me, with regard to the shell and scripting languages...

The shell is supposed to be a convenient interface for accessing the functionality your system has to offer - but because of the way that functionality is offered it's hard to take advantage of it. The shell hasn't got much in the way of support for datatypes, namespaces, and so on. This makes it a lot easier (and, often, more efficient) to program in a scripting language like Perl or Python, and implement all kinds of useful functionality as libraries for that language, instead of as shell programs.

So scripting languages have the advantage of providing a much more structured and full-featured programming environment - a better foundation on which to build more complicated programs and more sophisticated tools. But the whole thing is one degree separated from the normal interaction with the shell - it's not trivial to expose all that functionality implemented for the scripting language to code outside the scripting language... The scripting language becomes a rich environment all its own, but that functionality isn't part of the shell environment, because the shell environment doesn't support the organizational concepts that make that code manageable within the framework of the scripting language.

I feel like this situation is a problem - I believe in what some people call "The Unix Way" - chaining together small tools to do bigger jobs, but the shell doesn't have the organizational constructs to make this work for complex problems - and as a result people are doing this great work on adding functionality to the system, but it's getting packaged up as scripting language modules since the shell can't handle it. It's something I'd really like to correct.

Here in my car -- I make analogies
It is handy because -- you can relate to them
In cars...

Re: (Score:2)

by goombah99 (560566)

The original point of perl is to address your concerns. You want to be close the machine (in the unix not the C sense) but you want enough high level functionality. And you want to chain stuff.

Perl is the ultimate glue language. it's not so lovely as python or ruby but it's much more adapted for glueing and staying as close to shell scripting as possible. At the same time it has nice libraries that mean it can do so much more if you need to go there.

"Fascism should more properly be called corporatism, since it is the merger of state and corporate power"-- Mussolini

Re: (Score:2)

by Tetsujin (103070)

The original point of perl is to address your concerns.

But it's not a shell, and frankly I don't want it to be my shell.

My point is that I see the fact that we needed a strong string processing language to help with shell pipelining as a flaw in the way pipelines are handled. I also see the fact that so much good functionality is exposed as Perl or Python modules, but not as shell utilities, as indicative of a severe limitation in what the shell is capable of as a programming language (overcoming this limitation goes beyond just adding a stronger set of data t

Here in my car -- I make analogies
It is handy because -- you can relate to them
In cars...

Re: (Score:2)

by bar-agent (698856)
My point is that I see the fact that we needed a strong string processing language to help with shell pipelining as a flaw in the way pipelines are handled. I also see the fact that so much good functionality is exposed as Perl or Python modules, but not as shell utilities, as indicative of a severe limitation in what the shell is capable of as a programming language (overcoming this limitation goes beyond just adding a stronger set of data types to the shell language itself - the shell would also need to b

i'd hit it so hard, if you pulled me out you'd be the king of britain []

Re: (Score:2)

by SL Baur (19540)

I feel like this situation is a problem - I believe in what some people call "The Unix Way" - chaining together small tools to do bigger jobs, but the shell doesn't have the organizational constructs to make this work for complex problems - and as a result people are doing this great work on adding functionality to the system, but it's getting packaged up as scripting language modules since the shell can't handle it. It's something I'd really like to correct.

Small programs, doing one thing well is an idea that has lost in the marketplace of ideas. We can deal with it.

Philosophically, I am opposed to the methodology XEmacs (and other monolithic systems) represents, realistically, I can live with it - I have to. Practically, I've seen attempts at following the small piece model done so badly in the workplace that I'm not convinced anyone can make it work. For an Open Source example, see /bin/true in Stallman's GNU. Any real programmer would be ashamed of that

Beta index with the invisible article title means I don't have to read anything now before posting!

Re: (Score:2)

by nedlohs (1335013) []

Re: (Score:2)

by smoker2 (750216)

Perl is for CGI and private scripts separately. I would never give the shell power from the net. But I'm happy to run perl as CGI and bash from 0:1. I never mix the two. But you can pick on PHP if you want to get nasty about it. There is a perl [] shell [] available, but you need to know perl to use it properly. That's probably an obstacle to you, so yet another year without the Desktop crown then !

That which you give to another will become your own sustenance-if you light a lamp for another-your own way will be lit

Re:perl (Score:4, Interesting)

by ceswiedler (165311)
saying people should use Perl as an interactive shell? Or are you saying people should never use bash non-interactively?

The entire concept behind 'shell scripting' is to make it easy to tie together the same commands you type into the interactive shell. When I get used to doing 'rm' and 'cp' I can write an easy shell script which does the two together.

Of course, once you get to large shell scripts, then it becomes much more sane to use a real language rather than a shell script.

PowerShell 2.0 for Windows XP etc. by John D. Cook

November 2, 2009

PowerShell version 2.0 shipped with Windows 7 and with Windows Server 2008 R2, but it only recently became available for other versions of Windows.

The release of PowerShell 2.0 has been more like a leak than a product launch. The announcement page hardly reads like an announcement. The title reads "Description of the Windows Management Framework on Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008." What's this "Windows Management Framework"? I've never heard of that. I just want the new PowerShell. The first time I saw this page was when someone sent me a link saying PowerShell 2.0 was available for XP. I thought they'd sent me the wrong link by mistake because I didn't see anything about PowerShell at first. Only if you scroll down to the middle of a long page can you see links to download PowerShell.

I expected something more like the following.

1 iHunger 11.03.09 at 08:52

I thought the same thing when I looked at that announcement. If it wasn't for the twitter chatter, and that I REALLY want psh for XP, I might have missed it.

.2 Karl Meissner 11.16.09 at 15:13

Dont forget. You MUST manually uninstall powershell 1.0 for 2 to install correctly. In Add/Remove, click the checkbox "Show Updates" along the top, find Windows Powershell 1.0 and Remove it.

.3 John 11.16.09 at 15:16

Are you sure? I don't remember uninstalling version 1.0. Can the installation appear to succeed but not be correct?

.4 Karl Meissner 11.19.09 at 03:49

Not completely sure I guess. Uninstalling the old version was something your were supposed to do during the CTP. But I did not see that in the release notes of the RTM.

On my machine I had issues when the two powershell version were side by side. My remote desktop permissions stopped working. The issue resolved when I uninstalled 1.0 and installed 2.0.

So maybe it varies with environment….

.5 Adam Connor 03.23.10 at 12:32

The Windows XP install is bundled with WinRM, which I have no reason to want to install. Boo. Pass.

.6 John 03.23.10 at 12:53

Adam: That is unfortunate if you want to minimize whpx?FamilyId=f002462b-c8f2-417a-92a3-287f5f81407e">32 bit, 64 bit)

  • Server 2008 (32 bit, 64 bit)

  • Recommended Links

    Google matched content

    Softpanorama Recommended

    Top articles


    YouTube introduction


    General info:




    Windows PowerShell Script Repository
    Browse a repository of sample Windows PowerShell scripts.

    Getting Started

    Hey, Scripting Guy! Getting Started posts
    Take advantage of the Getting Started tag on the blog so you can easily find our beginner Windows PowerShell content.

    Scripting Guide

    Hands-On Scripting Labs

    Introduction to Windows PowerShell Virtual Lab

    Learn some of the fundamentals of Windows PowerShell by walking through this self-paced virtual lab.

    Writing Scripts with Windows PowerShell

    As a follow-up to Windows PowerShell Week, the Scripting Guys held a combination Virtual Lab/Webcast, known as a Labcast. This was a bit of an experiment, and while everything didn't go flawlessly during the live presentation, the Labcast is now available on-demand. You'll be able to walk through the Virtual Lab environment while the recorded version of the Webcast plays and guides you through the lessons.

    WinRM 2.0

    For more information about WinRM 2.0, visit the following Microsoft Web sites:

    About Windows Remote Management (

    What is New in WinRM 2.0 (

    Windows Management Infrastructure Blog (

    1. Windows PowerShell Blog
    2. Knowledge Base Article
    3. Windows PowerShell SDK
    4. Windows PowerShell Web Site
    Windows PowerShell

    Windows PowerShell Team Blog

    Keep up-to-date with the latest announcements directly from the team responsible for building Windows PowerShell. This blog is the definitive Windows PowerShell knowledge source for both developers and IT Professionals.

    Video Introductions of Windows PowerShell

    A number of introductory video tutorials demonstrate the numerous capabilities of Windows PowerShell including Introduction to Windows PowerShell, Windows Vista and Windows PowerShell, and Windows PowerShell and IIS 7.

    Windows PowerShell Getting Started Guide and Quick Reference

    This documentation pack is essential reading for beginners and advanced Windows PowerShell users. The Getting Started Guide and Quick Reference sheet provide useful tips and references on how to use the interactive shell as well as how to write and migrate Windows PowerShell scripts. The pack also includes a 100+ page Windows PowerShell Primer covering many basic and advanced topics.

    Windows PowerShell Newsgroup

    Join this popular community newsgroup for discussions on Windows PowerShell commands, scripts, and best practices.

    Windows PowerShell Scripts in the TechNet Scriop shop for all your Windows PowerShell scripting needs.

    Windows PowerShell on Hanselminutes (45 minute audio talk show)

    Scott Hanselman interviews Windows PowerShell Architect Jeffrey Snover. Hanselminutes is a weekly audio talk show with web developer and technologist Scott Hanselman.

    Free Windows PowerShell Book

    Free book covering Windows PowerShell available via MSDN. Requires Windows Live registration.

    Windows PowerShell SDK

    Developers and advanced script writers can leverage the SDK to create custom Windows PowerShell commands (cmdlets) and providers to simplify management of applications and the Windows environment.

    Windows PowerShell Web site (

    Windows PowerShell Online Help (

    Windows PowerShell Blog (

    Windows PowerShell Newsgroup (

    Windows PowerShell Software Development Kit (SDK) (



    Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


    War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


    Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


    Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

    Classic books:

    The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

    Most popular humor pages:

    Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

    The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

    Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

    FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

    This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

    You can use PayPal to to buy a cup of coffee for authors of this site


    The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

    Last modified: May 29, 2021