Softpanorama
May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Windows Powershell

News

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
(Cmdlet)
Windows PowerShell
(Alias)
cmd.exe / COMMAND.COM
(MS-DOS, Windows, OS/2, etc.)
Bash
(Unix, BSD, Linux, Mac OS X etc.)
Description
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

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.

 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 = '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
 PS> $UserProfile = $env:UserProfile
PS> [System.Windows.Forms.MessageBox]::Show('Hello, World!')
PS> [Array]$arguments = '-h', '15', 'www.google.com'
PS> tracert $arguments

[edit] File extensions

 


Top updates

Softpanorama Switchboard
Softpanorama Search


NEWS CONTENTS

Old News ;-)

[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: <nine.times@gmail.com> 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 [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:

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

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)

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

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 [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)

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

    Softpanorama hot topic of the month

    Softpanorama Recommended

    Resources

    Interviews

    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

    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

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

    What is New in WinRM 2.0

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

    Windows Management Infrastructure Blog

    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

    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

    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

    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 in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

    ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

    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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard 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 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


    Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

    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.

    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 make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

    Disclaimer:

    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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

    Last modified: November 01, 2015