Windows Powershell

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 1.0 was released in 2006 for Windows XP SP2/SP3, Windows Server 2003, and Windows Vista. For Windows Server 2008, it is included as an optional feature.
• Version 2.0 is integrated with Windows 7 and Windows Server 2008 R2 and is released for Windows XP with Service Pack 3, Windows Server 2003 with Service Pack 2 and Windows Vista with Service Pack 1.^[9]

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:

• Windows Remote Management (WinRM) 2.0 WinRM is the Microsoft implementation of WS-Management Protocol, a standard Simple Object Access Protocol (SOAP)–based, firewall-friendly protocol that allows for hardware and operating systems from different vendors to interoperate. The WS-Management Protocol specification provides a common way for systems to access and exchange management information across an IT infrastructure. WinRM 2.0 includes the following new features:
  • The WinRM Client Shell API provides functionality to create and manage shells and shell operations, commands, and data streams on remote computers.
  • The WinRM Plug-in API provides functionality that enables a user to write plug-ins by implementing certain APIs for supported resources and operations.
  • WinRM 2.0 introduces a hosting framework. Two hosting models are supported. One is Internet Information Services (IIS)-based and the other is WinRM service-based.
  • Association traversal lets a user retrieve instances of Association classes by using a standard filtering mechanism.
  • WinRM 2.0 supports delegating user credentials across multiple remote computers.
  • Users of WinRM 2.0 can use Windows PowerShell cmdlets for system management.
  • WinRM has added a specific set of quotas that provide a better quality of service and allocate server resources to concurrent users. The WinRM quota set is based on the quota infrastructure that is implemented for the IIS service.
• Windows PowerShell 2.0 New features that are introduced in Windows PowerShell 2.0 include the following:
  • Remoting Windows PowerShell 2.0 lets you run commands on one or more remote computers from a single computer that is running Windows PowerShell. PowerShell remoting allows for multiple ways of connecting. These ways include interactive (1:1), fan-out (1:many), and fan-in (many:1 by using the IIS hosting model).
  • Integrated Scripting Environment PowerShell Integrated Scripting Environment (ISE) enables you to run interactive commands and edit and debug scripts in a graphical environment. The main features include color-coded syntax, selective execution, graphical debugging, Unicode support, and context-sensitive help.
  • Modules Modules allow for 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 the module.
  • Advanced functions Advanced functions are functions that have the same capabilities and behavior as cmdlets. However, they are written completely in the Windows PowerShell language, instead of compiled C#.
  • Background jobs Windows PowerShell 2.0 allows for running a command or expression asynchronously and "in the background" without interacting with the console.
  • Eventing This feature adds support to the Windows PowerShell engine infrastructure for listening, forwarding, and acting on management and system events.
  • Script internationalization This new feature enables Windows PowerShell scripts to display messages in the spoken language that is specified by the UI culture setting on the user's computer.
  • Script debugging New debugging features were added to Windows PowerShell that let you set breakpoints on lines, columns, variables, and commands, and that let you specify the action that occurs when the breakpoint is hit.
  • New cmdlets Windows PowerShell 2.0 introduces over 100 built-in cmdlets. These cmdlets, excluding other tasks, enables you to do computer-related, event log, and performance counter management tasks.
• Background Intelligent Transfer Service (BITS) 4.0 BITS is a service that transfers files between a client and a server. BITS provides a simple way to reliably and politely transfer files over HTTP or HTTPS. File downloads and file uploads are supported. By default, BITS transfers files in the background, unlike other protocols that transfer files in the foreground. Background transfers use only idle network bandwidth in order to preserve the user’s interactive experience with other network applications, such as Internet Explorer. Foreground or typical transfers are also supported.
  
  BITS 4.0 includes the following new features:
  • Peer caching now uses Windows BranchCache. This new peer caching model replaces the model that is used for BITS 3.0.
  • A more flexible resource access model allows for applications to associate a pair of security tokens to a BITS transfer job.
  • The BITS Compact Server is a stand-alone HTTP/HTTPS file server that lets you transfer a limited number of large files asynchronously between computers.
  • More precise bandwidth throttling.
  For more information about BITS 4.0, visit the following Microsoft Web sites:

• 'cmdlets', which are .NET programs, written by a developer, compiled into a dynamic-link library and loaded by a PowerShell script,
• PowerShell scripts (files suffixed by '.ps1'),
• PowerShell functions,
• executable programs.

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.

Notes

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

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.

• Stop all processes that begin with the letter p:

 PS> get-process p* | stop-process

 PS> ps p* | kill

• Find the processes that use more than 1000 MB of memory and kill them:

 PS> get-process | where-object { $_.WS -gt 1000MB } | stop-process

 PS> ps | ? { $_.WS -gt 1000MB } | kill

• Calculate the number of bytes in the files in a directory:

 PS> get-childitem | measure-object -property length -sum

 PS> ls  | measure length -s

 PS> dir | measure length -s

• Determine whether a specific process is no longer running:

 PS> $processToWatch = get-process notepad
 PS> $processToWatch.WaitForExit()

 PS> (ps notepad).WaitForExit()

• Change the case of a string from lower to upper:

 PS> 'hello, world!'.ToUpper()

• Insert the string 'ABC' after the first character in the word 'string' to have the result 'sABCtring':

 PS> 'string'.Insert(1, 'ABC')

• Download a specific RSS feed and show the titles of the 8 most recent entries:

PS> $rssUrl = 'http://blogs.msdn.com/powershell/rss.aspx'
PS> $blog = [xml](new-object System.Net.WebClient).DownloadString($rssUrl)
PS> $blog.rss.channel.item | select title -first 8

$x=new-object xml;$x.load('http://blogs.msdn.com/powershell/rss.aspx');$x.rss.channel.item|select title -f 8

• Sets $UserProfile to the value of the UserProfile environment variable

 PS> $UserProfile = $env:UserProfile

• Cast a .Net Namespace, and call a method exposed by the cast

PS> [System.Windows.Forms.MessageBox]::Show('Hello, World!')

• Run a command line executable, with arguments.

PS> [Array]$arguments = '-h', '15', 'www.google.com'
PS> tracert $arguments

File extensions

• PS1 – Windows PowerShell shell script
• PS1XML – Windows PowerShell format and type definitions
• PSC1 – Windows PowerShell console file
• PSD1 – Windows PowerShell data file (for Version 2)
• PSM1 – Windows PowerShell module file (for Version 2)

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.

• PowerShell 'SmowerShell'-Why You Should Learn Windows PowerShell (Part 1) | WMA
• Heard It through the Pipeline-How to Compound Windows PowerShell Commands for Fun and Profit (Part 2) | WMA
• Sole Provider? Not Hardly-A Look at Windows PowerShell Providers (Part 3) | WMA
• The Main Event-Windows PowerShell Does Event Logs (Part 4) | WMA
• More Than Remotely Possible-Using Windows PowerShell to Manage the Remote Desktop (Part 5) | WMA

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.

• Windows PowerShell: Learn It Now Before It's an Emergency - Part 1 | WMA
• Windows PowerShell: Learn It Now Before It's an Emergency - Part 2 | WMA
• Windows PowerShell: Learn It Now Before It's an Emergency - Part 3 | WMA
• Windows PowerShell: Learn It Now Before It's an Emergency - Part 4 | WMA
• Windows PowerShell: Learn It Now Before It's an Emergency - Part 5 | WMA

NEWS CONTENTS

• 20210608 : PowerShell For Beginners Full Course - PowerShell Beginner tutorial Full Course ( Apr 21, 2021 , www.youtube.com )
• 20210528 : Powershell Video Tutorials "" CodingBee ( May 24, 2021 , codingbee.net )
• 20210422 : PowerShell For Beginners Full Course - PowerShell Beginner tutorial Full Course - YouTube ( Apr 22, 2021 , www.youtube.com )
• 20200112 : How to create and run a PowerShell script file on Windows 10 Windows Central ( Jan 12, 2020 , www.windowscentral.com )
• 20171117 : The Windows PowerShell Debugger ( Nov 17, 2017 , technet.microsoft.com )
• 20140905 : Slashdot discussion ( Sep 05, 2014 )
• 20140905 : Re:Powershell ( Re:Powershell, )
• 20140905 : Re: ( Re:, )
• 20140905 : Re: ( Re:, )
• 20140905 : Re:Powershell ( Re:Powershell, )
• 20140905 : Re:Powershell ( Re:Powershell, )
• 20140905 : Re:Powershell ( Re:Powershell, )
• 20140905 : Re:Powershell ( Re:Powershell, )
• 20140905 : Re:Powershell ( Re:Powershell, )
• 20140905 : Re: ( Re:, )
• 20140905 : Re:a fucking slideshow? ( Re:a fucking slideshow?, )
• 20140905 : The Great Dollar Dollar - Windows PowerShell Blog - Site Home - MSDN Blogs ( The Great Dollar Dollar - Windows PowerShell Blog - Site Home - MSDN Blogs, )
• 20110323 : Does Your Hard Work Advance the Ecosystem - Windows PowerShell Blog - Site Home - MSDN Blogs ( Does Your Hard Work Advance the Ecosystem - Windows PowerShell Blog - Site Home - MSDN Blogs, Mar 23, 2011 )
• 20100317 : Power Shell Usage Bash Tips & Tricks ( Power Shell Usage Bash Tips & Tricks, Mar 17, 2010 )
• 20100317 : Yes, PowerShell ( Yes, PowerShell, )
• 20100317 : Command substitution a "new idea?" ( Command substitution a "new idea?", )
• 20100317 : The Great Big Messy Book is back in print ( The Great Big Messy Book is back in print, )
• 20100317 : My /bin/sh rules ( My /bin/sh rules, )
• 20100317 : owerShell and critique of the Unix shell ( owerShell and critique of the Unix shell, )
• 20100317 : Re:PowerShell ( Re:PowerShell, )
• 20100317 : Re:Greenspuns Tenth Rule ( Re:Greenspun's Tenth Rule, )
• 20100317 : Re:Greenspuns Tenth Rule ( Re:Greenspun's Tenth Rule, )
• 20100317 : The Unix Shell and Scripting Languages ( The Unix Shell and Scripting Languages, )
• 20100317 : Re: ( Re:, )
• 20100317 : Re: ( Re:, )
• 20100317 : Re: ( Re:, )
• 20100317 : Re: ( Re:, )
• 20100317 : Re: ( Re:, )
• 20100317 : Re: ( Re:, )
• 20100317 : Re:perl ( Re:perl, )
• 20100317 : PowerShell 2.0 for Windows XP etc. by John D. Cook ( November 2, 2009 )

Old News ;-)

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

YouTube video

Apr 21, 2021 | www.youtube.com

Windows PowerShell [01] Introduction - YouTube

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

May 24, 2021 | codingbee.net

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 | www.youtube.com

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 | www.windowscentral.com

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="https://www.windowscentral.com/sites/wpcentral.com/files/styles/large/public/field/image/2019/01/run-script-file-powershell-remotesigned-windows-10_.jpg?itok=uUp-wanV" 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
• How to run a PowerShell script file on Windows 10

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="https://www.windowscentral.com/sites/wpcentral.com/files/styles/large/public/field/image/2019/01/write-host-script-text-powershell_.jpg?itok=RV6AyLZE" 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="https://www.windowscentral.com/sites/wpcentral.com/files/styles/large/public/field/image/2019/01/notepad-ps1-save.jpg?itok=GebEhNib" 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="https://www.windowscentral.com/sites/wpcentral.com/files/styles/large/public/field/image/2019/10/create-new-sp1-file-powershell.jpg?itok=WRgzqFRQ" 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="https://www.windowscentral.com/sites/wpcentral.com/files/styles/large/public/field/image/2019/01/powershell-ise-script-windows-10_.jpg?itok=_90-6cei" 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="https://www.windowscentral.com/sites/wpcentral.com/files/styles/large/public/field/image/2019/01/save-ps1-ise-script-windows-10.jpg?itok=waXgx8z3" 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="https://www.windowscentral.com/sites/wpcentral.com/files/styles/large/public/field/image/2019/01/powershell-set-executionpolicy-windows-10.jpg?itok=4_RbekrE" 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="https://www.windowscentral.com/sites/wpcentral.com/files/styles/large/public/field/image/2019/01/running-script-filies-powershell-windows-10_.jpg?itok=NY6tqO2Y" 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:

• Restricted -- Stops any script from running.
• RemoteSigned -- Runs scripts created on the device. However, scripts created on another computer won't run unless they include a signature of a trusted publisher.
• AllSigned -- All the scripts will run as long as they've been signed by a trusted publisher.
• Unrestricted -- Runs any script without any restrictions.

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:

• Windows 10 on Windows Central – All you need to know
• Windows 10 help, tips, and tricks
• Windows 10 forums on Windows Central

[Nov 17, 2017] The Windows PowerShell Debugger

Nov 17, 2017 | technet.microsoft.com

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:

• New-PsBreakpoint
• Get-PsBreakpoint
• Enable-PsBreakpoint
• Disable-PsBreakpoint
• Remove-PsBreakpoint
• Step-Into
• Step-Out

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:

cls
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:

• -script, followed by the path to the script we want to debug.
• -line, followed by the line number (4) where we want to place our breakpoint.

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:

Copy

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:

Copy

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:

Copy

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:

Copy

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:

Copy

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:

Copy

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:

Copy

Set-Location C:\Scripts
ConvertDate
Get-ChildItem

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:

Copy

Get-PSBreakpoint

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

Function: ConvertDate
Action:
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 
      session:

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:

Copy

(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

• There are several bad ways of finding previous lines from history
  • Many people go for pressing Up lots (and lots)
    • A tad inefficient, perhaps
• Ctrl+R searches previous lines
  • But Ctrl+R zip Esc doesn't find the last zip command - it also matches any line that copied, deleted, unzipped, or did anything else with a zip file
• Those of a gambling bent can chance ! and a command name
  • Irritating when !gv opens gvim instead of gv
• Sane Incremental Searching
  • Bash can cycle through lines starting in a particular way
  • Just type in a few characters then press Up
    • Don't need to press Up so many times
    • Don't see lines that merely contain those letters
    • Don't have to chance executing the wrong line
  • Incremental searching with Up and Down is configured in .inputrc

    "\e[A": history-search-backward
    "\e[B": history-search-forward

  • Old behavior still available with Ctrl+P and Ctrl+N
  • If that prevents Left and Right from working, fix them like this:

    "\e[C": forward-char
    "\e[D": backward-char

• Repeating Command Arguments
  • Commonly want to repeat just bits of commands
  • Very often the previous command's last argument
  • Meta+. retrieves the last argument. Press repeatedly to cycle through the final argument from earlier commands
• Magic Space
  • A magic space inserts a space character as normal
  • And also performs history expansion in the line much like Tab
  • See what you type before you commit to it
    • Press Space before Enter if necessary
  • Magic Space Set-Up
    • Magic space is configured in .inputrc
    • Redefine what Space does
    • There are other readline-based programs without this feature, so make it only apply in Bash:

      $if Bash
        Space: magic-space
      $endif

• Forgetting Options
  • Common to forget an option from a command
  • Want to rerun the command with the option
  • Go to the previous history line, then move just after the command name to type the option
  • Can set up a keyboard macro to do this
  • Insert-Option Macro
    • Meta+O can be made to load the previous command and position the cursor for typing an option
    • Defined in .inputrc:

      "\M-o": "\C-p\C-a\M-f "

      • Ctrl+P: previous line
      • Ctrl+A: start of line
      • Meta+F: forward a word, past the command
      • ␣: insert a space
    • 17 unused keystrokes with just Ctrl or Meta modifiers

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:

• List all .exe files in current dir and below: ls -r . *.exe
• Calculate their combined size: ls -r . *.exe | measure -sum Length
• Find the latest version of all .exe files below the current directory: ls -r . *.exe | sort -des LastWriteTime | group Name | %{$_.Group[0]}
• Instead of finding the latest, delete those with a more recent version somewhere: ls -r . *.exe | sort -des LastWriteTime | group Name | %{$_.Group|select -skip 1} | rm
• Read files and directories from current directory out loud through the speakers: $sam=new-object -com SAPI.SPVoice; ls | %{$sam.Speak($_)}
• List processes consuming (the "working set") more than 100MB: ps|?{$_.WS -gt 100MB}
• -Kill them instead: ps|?{$_.WS -gt 100MB}|kill
• Wait for the "import" process to exit: (ps "powershell_ise").WaitForExit()

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 [wikipedia.org], 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 [dpbsmith.com]

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:

• Anything that can be done in /bin/sh I DO in /bin/sh.
• Anything slightly more complex I do in Perl.
• Anything truly complex I write in Java.
• For writing scripts I NEVER, EVER use slightly enhanced shells like (t)csh (know for having bugs), ksh (used to be proprietary) or bash (too many features I DON'T want for simple scripts).
• People that resort to slightly enhanced shells for scripting qualify themselves as being ... let's say ... inexperienced.
• It pisses me off when I have to look up special csh, ksh or bash constructs in order to understand scripts.
• Fancy variables? Reconsider or write Perl.
• Fancy condition checking? Reconsider or write Perl.
• Fancy arithmetic? Reconsider or write Perl.
• Fancy system access (e.g. ipc)? Write Perl.
• However, my favorite INTERACTIVE shell is bash. It gets the /bin/sh syntax and offers stuff that makes you extremely quick when working interactively.

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)

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)

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)

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 [bash.org]

Re: (Score:2)

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)

http://www.focusresearch.com/gregor/sw/psh/ [focusresearch.com]

Re: (Score:2)

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 [sourceforge.net] shell [wikipedia.org] 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)

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

Sites

YouTube introduction

• You Should Learn PowerShell - YouTube
• PowerShell For Beginners Full Course - PowerShell Beginner tutorial Full Course - YouTube
• Windows PowerShell [01] Introduction - YouTube
• Learn and use PowerShell with just three commands - YouTube
• Learn PowerShell - Video & Blog Series - YouTube
• PowerShell Input & Output - YouTube

Sheetsheets

• PowerShell Commands Cheat Sheet - Basic Commands You'll Need +PDF
• PowerShell cheat sheet for cmd.exe users

General info:

• Monad Shell (MSH)
• Channel 9: Jeffrey Snover - Monad explained
• Channel 9: Jeffrey Snover - Monad demonstrated
• WinHEC slides
• The .NET Show: Longhorn Fundamentals
• Installing Monad on XP or Win2k3
• MSH Language Quick Start
• PowerShell

Resources

• MSH Wiki including a quickstart language reference and FAQ
  
• Use PowerShell to Look for Phone Numbers in Text
  
• Scripting Wife Uses PowerShell to Get Lines from a File
  
• Use PowerShell to Replace Text in Strings
  
• Scripting Wife Uses Regular Expressions to Match a String
  
• Scripting Wife Uses PowerShell to Get Days Until NCAA Final Four
  
• FAQ for the PowerShell 2011 Scripting Games
  
• Use PowerShell to Document Exchange Server Prior to Upgrade
  
• Use PowerShell to Determine Fragmentation of Your Drive
• More Windows PowerShell Blog Posts >

Interviews

• Ed Wilson Shares Windows PowerShell Best Practices
  
• CodeCast Episode 76: Windows PowerShell for Developers with Ed Wilson
  
• Get-Scripting Podcast Episode 16 - (Ed Wilson - The Scripting Guy)
  
• Episode 96 – Scripting Guy Ed Wilson on Windows PowerShell Best Practices
  
• Episode 50 – Ed Wilson – Microsoft Scripting Guy!
  
• Ed Wilson is a Scripting Guy!
  

Scripts

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

• Windows PowerShell Owner's Manual
  

  Here's the guide for learning Windows PowerShell from the ground up.

• VBScript to Windows PowerShell Conversion Guide
  

  Are you a VBScript script writer looking to try your hand at Windows PowerShell? Then you might want to take a look at our conversion guide which shows you how to replicate VBScript functions and methods in Windows PowerShell.

• A Task-Based Guide to Windows PowerShell Cmdlets
  

  This guide focuses on the tasks you can carry out using cmdlets. Read and write text files, manage event logs, sort data, and much more.

Hands-On Scripting Labs

WinRM 2.0

About Windows Remote Management

http://msdn.microsoft.com/en-us/library/aa384291(VS.85).aspx (http://msdn.microsoft.com/en-us/library/aa384291(VS.85).aspx)

http://msdn.microsoft.com/en-us/library/ee309369(VS.85).aspx (http://msdn.microsoft.com/en-us/library/ee309369(VS.85).aspx)

http://blogs.msdn.com/wmi (http://blogs.msdn.com/wmi)

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

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.

Windows PowerShell Web site

http://www.microsoft.com/powershell (http://www.microsoft.com/powershell)

Windows PowerShell Online Help

http://technet.microsoft.com/en-us/library/bb978526.aspx (http://technet.microsoft.com/en-us/library/bb978526.aspx)

Windows PowerShell Blog

http://blogs.msdn.com/powershell (http://blogs.msdn.com/powershell)

Windows PowerShell Newsgroup

http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.windows.powershell (http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.windows.powershell)

Windows PowerShell Software Development Kit (SDK)

http://msdn2.microsoft.com/en-us/library/aa830112.aspx (http://msdn2.microsoft.com/en-us/library/aa830112.aspx)

Etc

Society

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

Quotes

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 quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

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

History:

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 DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting 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-Month :  How 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

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