Talk:Windows PowerShell

From Wikipedia, the free encyclopedia

 This article is part of WikiProject Microsoft Windows, a WikiProject devoted to maintaining and improving the informative value and quality of Wikipedia's many Microsoft Windows articles.
B This article has been rated as B-Class on the assessment scale.
Mid This article has been rated as mid-importance on WikiProject Microsoft Windows's importance scale.

Contents

[edit] AmigaOS heritage?

Several of the mentions of this on other articles that I edited in creating this article mentioned MSH taking features from AmigaOS, but as yet I've found no reference to what these might be (and I have no direct experience with either). Anyone care to fill in the details? - IMSoP 01:31, 21 Jun 2004 (UTC)

I'd say that it's more likely to have taken various things from Unix. Pipes, for example. But I have no experience with AmigaOS.
Pipes have been available in cmd.exe for years, they're not new in MSH. I don't have any experience with AmigaOS either, but I think the features they were talking about there were the ability to have other system stores (e.g. registry, etc) mapped to drives and navigated like a normal file system. As they do so often, Microsoft have looked at what they believe to be the best features of predecessors to what they are trying to make (AmigaOS, Bash, etc), combined them together in a consistant and intuitive way, and thrown out the challenge to the old standards to continue to improve to keep up.
The AmigaDOS (not really Amiga*OS*, IMHO) similarities may be from AmigaDOS' more abstract system with devices. Instead of the DOS way with A: to Z: for a strange mix of devices that can be anything from floppy disks to USB cameras, or the Unix way with /dev/cdrom, etc, it may use things like REGISTRY:, etc, which is similar to how AmigaDOS did it with e.g. LIBS: etc. However, even that wouldn't be a major similarity, as I believe msh will have C: become FS::C: or something like that... So I don't mind removing the AmigaOS stuff as I doubt there are any major similarities going on.
I think it is because drives can have names other than A: to Z:. There's nothing wrong with pointing out the similarity: it's a good idea to make it clear that not every idea is an inovation out of nowhere. Calling it a "heritage" gives the impression that MSH derives this feature from AmigaDOS code though. Rob Russell 17:39, 4 October 2005 (UTC)
I've heard great things about AmigaOS but unfortunately have not had any experience with it. PowerShell's object-oriented Namespaces are very similar to the fantastic Object Oriented Filesystem of Apollo's DomainOS. I worked on Domain/Access a product which leveraged that FS to access remote VMS filesystems. Jeffrey Snover - Windows PowerShell Architect


If it is for the aliases meant for aliasing logical device names such as DH0: or DF0: on the Amiga, then monad or the Vista system clearly derives from that. Perhaps this is because Bill or some other jerk from out of their development apartment got hold of some old documents once ago submitted by Commodore for their development of the Amiga Basic, which is, actually, by far the best example on how far M$ has come with multi tasking since then. Amiga Basic was the only system doing busy looping in an otherwise event based system. Furthermore, it was the only system that would have stalled the overall hosting system by running just a few tight for loops. Somehow, this reminds me of the more concurrent non-solutions (just ranting ;-) provided by that company for todays markets...
Apart from that, assigning aliases to existing logical device names, making them sort of more virtual and overall more reusable was a very good concept. Something like that we may find in current and past unix derivates, from which, essentially, AmigaDOS is a blatant rip off, although I do not remember the original system on which that beast was once based on. —The preceding unsigned comment was added by 87.78.187.33 (talk) 23:16, 22 January 2007 (UTC).
AmigaDOS most certainly was not a rip off from unix — at least not directly any more than MS-DOS or even VMS! It is true that it shares many of the command line characteristics of Unix, like having
  • a hierarchic file system with similar naming conventions (forward slashes "/" between path components)
  • input and output redirections ("command <input.text >output.text")
  • pipes ("command1 | command2")
but there were also considerable differences like the idea that file systems are served by modular drivers called Handlers which were really meassage passing (see Inter-process communication) processes existing outside Amiga's (micro)kernel Exec.
In truth, AmigaDOS (and I mean the input/output routines of the operating system) came to be based on TRIPOS — a research OS developed in the late 1970s at the Computer Laboratory of Cambridge University in England. In 1985 the in-house OS CAOS (short for Commodore-Amiga Operating System, see [1]) remained incomplete and Commodore was forced to commission Metacomco, a British company from Bristol, to port the Motorola 68000 based version of TRIPOS to Amiga to fill in the gaps. The Amiga software team wasn't happy about this turn of events but caved-in due to the impending release of Amiga 1000. Ironically (and this is what-if speculation) Amiga's then software manager Andy Finkel has stated that had they been able to complete CAOS in time, it would have resembled Unix so much that it would have made porting Unix software rather easy. AmigaDOS/TRIPOS wasn't really all that good of a match for Unix underneath the hood. And no surprise there because TRIPOS was written with BCPL, a predecessor to the now ubiquitous C language with quite different calling conventions etc.
Lastly more on topic, the contributions which AmigaOS/AmigaDOS may have effected on Windows have been of much dispute during the years. Especially when Windows 3.0 was released (1990), it was widely speculated in the Amiga community that the idea of dynamically-link libraries was partially influenced by Amiga's shared libraries. Yet there were predecessors like Multics which had already in the 1960s most of the features (including dynamic libraries) we find irreplaceable in a modern operating system. Unix, VMS, AmigaOS, OS/2, Windows etc., were all bastard children of Multics — they all inherited and adopted concepts from their predecessors and peers. Why should it be any different with a single OS component like the Windows Powershell — likewise it has predecessors and peers which have influenced it. Not very much happened on the command line front in Windows for years (eg. even WSH wasn't very conducive to interactive tasks like the Unix shells), so maybe it isn't surprising that PowerShell/Monad started with a clean slate and thus was willing to adopt several ideas from competing OSs and programming languages. —jibun≈παντα ρει≈ (keskustele!) 05:23, 3 March 2007 (UTC)
My guess is that the Amiga reference would be to ARexx. The UNIX match might be TCL. This approach depends on there being a pile of interesting programs that expect to be connected through such a shell. UNIX doesn't have such a pile, but it does have a pile that expect pipe glue. I have no idea if the Amiga had (has?) such a pile. DHR 03:53, 9 May 2007 (UTC)

[edit] Tab completion

The CMD shell it's replacing has tab completion. Is the features list meant to show what's new or just a list of all features? --Jtatum 16:43, 19 Jun 2005 (UTC)

Hm, interesting, it seems they turned that on by default in Windows XP; I actually discovered how to turn it on by mistake under Windows 2000. Even so, if it's the same functionality it's a very limitted kind of completion, being limitted to filenames (or, using an alternative setting, directories) rather than commands (or the fully programmable completion offered by, for example, bash). Perhaps "* full tab completion facilities" would be better? - IMSoP 02:55, 11 November 2005 (UTC)
Maybe "more complete" or just "better" instead of "full"? "Full" is too strong a term, IMO. --tyomitch 08:36, 11 November 2005 (UTC)
Can someone please describe the fuller/better programmable completion that bash has so we know what's better instead of just saying that bash has it better? 69.86.230.76 20:28, 27 February 2007 (UTC)
I believe the article would be improved if it said what things PowerShell can tab complete compared to cmd, rather than comparing cmd to bash and zsh. Unfortunately I don't know what things PowerShell can complete (although I'm guessing/hoping at least registry keys) so cannot update the article myself. Pelago 09:07, 3 May 2007 (UTC)

[edit] MS or Microsoft

Why the hell does everyone keep changing "Microsoft's" to "MS's"?

Because MS is the abbreviation of Microsoft, there is some confusion about which should be used in wikipedia I guess. --Netdroid9
I'd go with Microsoft's; it's more professional looking. However, don't go around putting in (R) or TM. That just starts to look silly. 128.42.152.114 08:10, 19 December 2006 (UTC)
Under the hood, all of the acronyms MS, M$ and even the fully spelled acronym Microsoft, is very and highly unprofessional. Why give them a touch of professionalism where there is none? —The preceding unsigned comment was added by 87.78.187.33 (talk) 23:09, 22 January 2007 (UTC).

[edit] "Based on UNIX?"

The MS-DOS and NT command-line shells (and QDOS before them) were based on CP/M, not UNIX.

Response: Then update the article!
Pipelines were. 24.87.114.179 17:33, 5 August 2006 (UTC)

[edit] Usability- Is it?

We all know that the new CLI by MS is nothing more than a shell for accessing objects of the kernel and operating system via a rather incomplete and complex interface, far much more complex than for example a standard ksh or zsh or even bash.

How can one render something as bad as that worthy of being discussed in the Wikipedia and even get an entry in the encyclopedia?

My reckoning is that we should at least link from FUD towards here or completedly delete this article as it is nothing really worth talking about in an electronic book that provides knowledge and not semi-knowledge on a future non-product of a company trying to lower the quality standards of the wikipedia since they are loosing ground with their own encyclopedia.

Remove the article on the MSH I say.

He who removes this entry in the discussion should be warned, I will restore it as soon as it becomes deleted. The quality of the wikipedia is not to discuss or provide a forum to any products of any company that are for now and will be non-products, nor to discuss FUD beyond what is already present in the wikipedia.

Oh, shut up. --Yath 04:32, 23 Jun 2005 (UTC)
Oh, why? Should I post the ongoing process of a project that I have been developing, largely since 1998, which is mostly equal to that of the .net framework but based on the Java language? Should I discuss that my ideas from 2001 contained such a command shell in which I could access objects of the kernel and os and invoke methods on them because the system provides for these ideas inherently? Wouldn't that be the same as discussing a product of one company that is not necessarily history nor of any relevance to both the past and future of computing in a forum where there exists no space for these kind of discussions? At least IMHO, as always. So I keep shut up with my project, let others do the same on theirs. If they need to discuss such products, they could setup a wiki on their own and discuss it there - keep knowledge in the Wikipedia, not simple information on non-topics.
I think this is a fair enough debate to be having, but I don't agree with your position in it; there are 2 main reasons why, IMHO, this (and other Windows Vista-related information) are encyclopedic:
  1. They have been announced as the future direction by the single dominant player in the desktop operating system market. This, even if the developments prove to be vapourware, has a knock-on effect on anyone and everyone else hoping to compete. At the very least, it makes the ideas "hot topics".
  2. Many of these features are available - this article provides links to a public beta of MSH. Had you posted your attack (I can't think of a better term) in reference to WinFS, this defence would not be available; it quite possibly is nothing more than vapourware.
The main Windows Vista article (which has attracted similar comments) is different again, since it's almost 100% certain that there will be a "next version" of Windows, and that that will be a significant event, and discussions of its development are notable (see point 1, above). So, although no such software really exists yet, it would seem like a gap not to mention it. For me, the first point is enough to justify WinFS having an article, too, but that's a different discussion.
Now, neither of these reasons, AFAIK, apply to the project you mentionned: the development is not being done by a major player in the market, and other players are not closely watching developments; and you only mention it being an "idea", not in active development and available for public beta testing.
On a final note, I fully agree that we need to think carefully how we present such articles, so that they don't come across as swallowing the hype whole, but I don't think not mentioning these things at all is a valid counter to that. --IMSoP 12:12, 23 Jun 2005 (UTC)
I fully agree, it was initially only the attempt to not let go unreflected the notion of Wikipedia becoming more or less an unreflected platform for (hidden) corporate product placement and advertisement, adorsement or whatever fandom brings people to actually include such articles in an encyclopedia; even if it is done by said fans of these platforms and products who firmly believe in the good of those products and platforms and firms. That these platforms and products are a hint on future systems to come, and not necessarily by any of the global players we currently are talking about, is of course true and is a requirement for information technology reformation and sort of revolution in the field of automization of development and of system operations, aka shells such as the monad shell. And yet, with all the hype currently going on about the next version of the operating system, we also find that it was cancelled for the home releases due to _potential standard shell behaviour and potential standard user and system operator misbehaviour_ that defines that only who is capable and sane may program and run shell scripts in an unsafe environment, such as if you are root on a different operating system and fiddle with rm -Rf $1 in a shell script that, when being executed as doSomething ".*" will not only delete the current directory but also recursively every other directory available on the filesystem. Why should we bother about this? (And believe me, I know what I am talking about here, once, erm twice, I was insane enough to actually commit this once to the parser of bash.) It is the sanity of the people that leads to safer systems, not the insanity of some corporation that drives people nuts with their problem of never to be solved insecurity and instability and incompatibility whatever. So we should perhaps also include this information as well, I mean, people need to know, don't they? And yes, forget it, I was just insane enough to try to repair Windows XP Home and install some software the other day. Recovery and that crazy user whose laptop I installed finally made my day. I wonder what would have happened if monad came into play? Would it be an even crazier experience than before - with even more unknown error messages and failures where there should be progress and success? Ever seen the .net assistents to edit the "security policies" of .net applications? will monad be a .net application? What about usability, understandability, knowledge for the casual user? Security? Either nothing will work correctly ever again due to DEP, or is totally insecure in a sortof runtime limited root environment. People have to know - and it is fact, we should include this knowledge in the article as well - at least IMHO, as always.

Kind of in-line with the discussion that's going on here, but more just to maintain an encyclopedic tone, I've done a little trimming on the article when it seems to go in to the reasons behind MSH functions. No offense meant (unless you're MS undercover), I'm just trying to keep it fact-based and leave opinions out. In line with that, can we clarify what an object is in this context? Is it a .Net object? Is it a COM object? This article doesn't seem to be as technical as it could be. I'm looking around for more references on it though. Rob Russell

AFAIK they are .Net objects.
Where technical references are concerned, a good place to start would be Microsoft's own MSH wiki. Haeleth 19:42, 4 October 2005 (UTC)
AFAIK, yes they are objects instantiated in the CLR. However, WMI is another topic that should be included here, as that was one interface that was very badly documented back then. WMI is used for accessing operating system objects using a more or less standardized management interface (MI) for windows (WMI). I believe that most of the objects accessed will be only semi wrappers that will delegate remote method calls to the underlying still old and functioning WMI extensions introduced to windows. Sort of XMLRPC that is, when calling the objects provided by the WMI, I reckon...


Here is some more information laying even more ground to my initial consent against including any future to be released, still non-alpha products of certain firms http://yro.slashdot.org/yro/07/01/22/2056214.shtml The link and information contained therein is actually stating what I tried to tell you back then (I was the original author / editor) of the part discussion thread), in short, it states that M§ tried to persuade certain third persons to edit articles in their favour in order to get rid of unwanted commentaries...

"We all know that the new CLI by MS is nothing more than a shell for accessing objects of the kernel and operating system via a rather incomplete and complex interface, far much more complex than for example a standard ksh or zsh or even bash." Aren't ksh, zsh, and bash all shells for "accessing objects of the kernel and operating system"? If they're somehow different, it should be mentioned somewhere. Herorev 10:17, 7 April 2007 (UTC)

[edit] A note on viruses

There are various "proof-of-concept MSH viruses" that have been floating round (and that a few people have tried to add to the article). I would argue that these are not notable: they have not been made possible by any new feature or flaw of MSH, they are merely straightforward ports of existing trojan scripts, which exist for pretty much every shell and scripting language there is.

Given that there are as many AppleScript "proof of concept viruses" out there as MSH ones, and yet nobody seems to be trying to add that fact to that article, I am forced to conclude that the people adding details of MSH "viruses" to this page are vandals. If any contributors actually believe in good faith that MSH "viruses" are sufficiently notable to deserve mention in an encyclopedia, I request that they attempt to justify their belief here before making edits. Haeleth 23:15, 3 October 2005 (UTC)

It's also worth noting that the two principle viruses released (by the same person), respectively for Monad and Powershell are, as the original commentor notes, little more than simple ports - if you look at the code, it's very clearly been rewritten from existing VBscript code based on the structure and the objects it uses. Even the latest, "polymorphic", powershell virus exhibits these traits, although some of the more blatant aspects of the port have been removed (the first "virus", which was little more than a list of commands in a file, used the 'tskill' command to end processes, rather than the stop-process cmdlet). This not-really-polymorphic not-a-very-good-virus, then, isn't even actually fully written in powershell. Given the press this has generated, I think it's worth mentioning because it's generated that press, but with a (sensible) commentary on the precise significance of the "virus", and what degree of thread / quality of code / actual technological significance it has. 23:15, 03 August 2006

[edit] Heritage should be included!

MS clearly borrowed from Perl ($_), SQL (select,where), Unix-Shells (Pipes, though available in command.com and cmd.exe), Ruby (Everything is a class), and more so. This is not to say that borrowing is bad, it should just be pointed out that this - like every technology - did not come out of the blue sky.

Mixing all this concepts together to create something that works is achievement enough. LuckyStarr 21:41, 24 October 2005 (UTC)

You're right: something definitely needs to be said along these lines. Go ahead, be bold and add a section on the subject! Currently the article doesn't seem to mention any influences at all! Clearly perl, sh, and SQL were all influences. (I'm less convinced by Ruby.)
It may be best, however, not to be too specific about what came from where. $-notation for variables is older than Perl, for example - consider its use in some circumstances in the Bourne shell, or its use in AWK for field bindings.
The really important thing is to make sure the article isn't claiming that anything derivative is original. People who are interested in heritage can always investigate further, if the links are there for them to follow, so quality of facts is more critical than quantity.
— Haeleth Talk 22:05, 24 October 2005 (UTC)


It seems that there are individuals blocking any such mention. This raises the general issue of Microsoft articles in Wikipedia: that there is much un-encyclopedic activity afoot, not to mention a lot text that almost exactly echoes Microsoft marketing department. Is Microsoft still actively tinkering with wikipedia? —Preceding unsigned comment added by ElectronicsEnthusiast (talk • contribs) 06:20, 28 April 2008 (UTC)

[edit] Examples?

I'd like to see some short example scripts. I don't know enough about MSH to do it myself. --68.198.246.166 16:29, 11 January 2006 (UTC)

[edit] Name change

I thought the name MSH was excellent, why'd they have to go Marketize it? "PowerShell" sounds like a lame gas station. --Disavian 14:46, 26 April 2006 (UTC)

Well, this explains why the name was changed :-) --soUmyaSch 15:03, 26 April 2006 (UTC)
Ah, those marketing types inflicted this upon us :/ -Disavian 13:46, 28 April 2006 (UTC)

[edit] WikiBook Link Broken

The title says it all.the1physicist 20:38, 28 May 2006 (UTC)

[edit] Leibniz

I don't notice that the irony of the name has been pointed out sufficiently. On the wiki page for this topic there is some mention of Leibniz and how his monads are in "pre-established harmony", and then some blather that attempts to connect that concept to the PowerShell idea. But that's not where the name comes from. Leibniz's monads are said to be "without windows," meaning that they have no ability to communicate between each other and that all correspondence of perspective between them is due to that same pre-established harmony.

So, if you're working in Vista, and you want to change your interface to a shell interface, so that you can work "without windows," where do you go? Into Monad, of course.


Good catch (not many people pick up on that one). That said, the primary reason I chose the name was because of the compositional nature of Monadology and what we were doing. Jsnover 18:51, 15 August 2007 (UTC)

[edit] PowerShell Scripts?

Where can people submit PowerShell Scripts? --FreAsQ 04:13, 30 October 2006 (UTC)

Here:

Community-Submitted Scripts Center

and here:

Windows PowerShell Contest

[edit] Job control

"One option for dealing with errors is to invoke a "suspend" feature which allows the user to enter a new command shell, investigate a problem, and resume the original command. A simple mechanism lets the programmer define the prompts to be shown in such circumstances."

Isn't this just "job control", or am I missing something exciting and new? - Francis Tyers · 16:47, 21 February 2007 (UTC)

[edit] Whining

It seems that there isn't enough knee-jerk criticism of Microsoft in this article. Perhaps the POV rules of wikipedia could be waived so that the article can be made, I dunno, more sneery. I just think it's a bit unfair to all the people who dont like MS that they have to read this article and as a result get all agitated and generally butt-hurt that it doesnt conform to their worldview. —Preceding unsigned comment added by 62.189.46.50 (talk • contribs) 12:13, 22 February 2007

How about... no. —Disavian (talk/contribs) 16:55, 22 February 2007 (UTC)
I'd go a small way in the direction you propose. I'd eliminate the marketing phrasing like "Windows PowerShell is the foundation of the administrative experience..." and "scripting language with many power user features". By that argument, I'd be tempted to remove "PowerShell" but that is going too far. DHR 04:00, 9 May 2007 (UTC)
I agree to getting rid of the marketing phrases like "foundation of blablabla". PowerShell in itself is already a marketing phrase, no need to further expand on the terminology. However, at the same time, I propose to remove all the lines which state "citation needed". It disturbs reading the article if there are so many "lacking citations" IMO. —Preceding unsigned comment added by 80.108.103.172 (talk) 12:11, 6 November 2007 (UTC)

I very much agree with the vetting of the Microsoft marketing department from Wikipedia; I think that PowerShell is an important improvement to the MS line of operating systems, but I don't want a brochure in my encyclopedia - it's un-encyclopedic and against the guidelines of wikipedia, but it seems every article I read about microsoft technology has marketing text in it. I think it's something that needs to be addressed by the wikipedia community, as well as by microsoft enthusiasts. P.S. two wrongs don't make a right, and three rights make a left. ElectronicsEnthusiast (talk) 06:34, 28 April 2008 (UTC)

This is what I hate about the *Nix enthusiasts who come and read MS-related articles; they start accusing the editors of being on MS payroll and blah blah blah, without any evidence whatsoever. Why not show some respect and assume that these things do not stand out to the regular editors because of their extreme familiarity with the text? Things would be much better if instead of whining you do a polite and constructive criticism by doing an unbiased review of what is problemmatic (I am talking about articles that are "maintained" by experienced wikipedia editors; a quick test - if the talk page is full enough, the article probably is). The whining gets you nowhere, it only irritates the editors to be dismissive of you. --soum talk 06:47, 28 April 2008 (UTC)

[edit] reception/usage

is there any information on the reception and/or usage of this shell?

Yes - it is being adopted at quite a clip. In 6 months there were a million downloads. There are more details in this post on the PowerShell team blog: [2]. Jsnover 18:49, 15 August 2007 (UTC)

[edit] Central Concepts

The second paragraph makes unsupported claims that are not obvious to me.

This eliminates much need for the many text-processing utilities that are common in UNIX pipelines, such as grep and awk, and allows things to be combined interactively (or in a scripting environment) without pressuring for the usage of a more complex programming language.

Why does this eliminate much use of grep and awk? What is this pressuring? How does it allow things to be combined interactively (does this actually mean that they can be combined in a way that they can interact)? DHR 20:51, 14 September 2007 (UTC)

This needs to be clarified. The language is a mess. What it means is that the output in most UNIX shells is only an unstructured (from a computer point of view) text stream. To extract certain information from the text, it needs to be further processed using grep and awk. The more complex structure the output has, the more complex a grep or awk search becomes. With PowerShell, as the output is an object in itself, the output stream is structured, so the required information is made readily available by simply accessing the proper fields in the object. This does not mean that text processing utilities cannot be used, it means that they need not be used to parse the output. --soum talk 07:34, 15 September 2007 (UTC)
be bold: If you know what it is trying to say, and that is something that should be said, make it say it. I fixed the next sentence but didn't touch the quoted portion because I didn't get it.
grep is not usually about decoding the structure of a stream but about selecting a portion of it. Surely you need tools to select elements of a stream of objects. If that is a win, that should be explained. It certainly isn't made clear in the quoted text. AWK usage is harder to characterize (and AWK usage is probably fading in the UNIX world anyway). To make the statement reasonable, it needs to explain what usage is obviated. DHR 16:55, 16 September 2007 (UTC)
Its not a question of being bold. Its a question of time. I plan to rewrite this article in entirety, but due to lack of time am not being able to do it currently. If anyone else wants to tackle, be my guest. I am available for any information and clarification.
As for "grep is not usually about decoding the structure of a stream but about selecting a portion of it", you cannot select a portion without parsing the stream. That what I said. When converted to text, the data is no more structured (sure, it might be tab delimeted or space delimited, fixed width etc, but such formatting has meaning to users. Not the computer. To it its just a string of characters). Without a separate parsing program, the computer cannot separate individual elements from the data. But with objects, the system has information about the schema of the data. All data elements are typed and the system already knows where one element ends and other begins. So, these can be directly accessed (by accessing proper fields in an object) without requiring any separate parsing script.
Its just like with object oriented languages. As long as the data is live as objects, any supported operation can be invoked natively on the data in the object or a subset of it. If it is serialized to plain text, it must be deserialized back to live objects with a separate parsing script before incoking the actions again. Since all cmdlets understand live objects, they are the data communication format, rather than a serialized-to-text version of the data. Thus the intermediate steps of first formatting live objects to text and then parsing text to live objects are avoided.--soum talk 08:32, 17 September 2007 (UTC)
And "combined interactively" is a bad term. All it means is that the schema of the output object is preserved as it is passed to the next cmdlet in the pipeline. --soum talk 07:35, 15 September 2007 (UTC)

The first sentence of the paragraph looks questionable too.

If invoked individually from the command line, a cmdlet's output is converted automatically into text, but if its output is to be used by another cmdlet, it is converted into the appropriate object type for the receiving cmdlet.

How does PowerShell know (chose) the appropriate object type? That is a very tricky design space -- what choices were made? Surely the case of output to screen is just an application of whatever rule(s) they use. DHR 16:55, 16 September 2007 (UTC)

Well, no magic happens here. Since all powershell objects are derived from the Object class in the .NET Framework, they all have the .ToString() method which serializes the data to text and formats for screen (or file) output (If the data is to be used after this point, it must be parsed and deserialized to live objects before it can be used, just like regular shells). PowerShell simply calls the .ToString() method of the object returned by the last cmdlet in the pipeline. For all other cmdlets, the object returned by them are passed as it is to the next cmdlet which invokes whatever methods it likes. --soum talk 08:32, 17 September 2007 (UTC)

[edit] Influenced by

Why can't this be added?

|influenced_by = bash, zsh, Perl, Ruby, .NET, DOS


and is it correct?

Do you have a reliable source that says the same? Failing that, it is just unverifiable original research. No matter how similar they look, it will not be obvious to all of the readers of this article. As such, claiming this requires a citation. --soum talk 23:39, 19 January 2008 (UTC)

In fact, the similarities are striking: but for purposes of citation, here is an excerpt from the official documentation from microsoft. This is only one of several citing external influences. ElectronicsEnthusiast (talk) 07:18, 28 April 2008 (UTC)

Windows PowerShell was designed to take advantage of a user's historic knowledge of CLIs. In this chapter, we will talk about some basic tools and concepts that you can use to learn Windows PowerShell quickly.

They include:
·      Using Get-Command
·      Using Cmd.exe and UNIX commands
·      Using External Commands
·      Using Tab-Completion
·      Using Get-Help
Jeffrey Snover, Microsoft PowerShell Architect, named C#, DCL, KSH, Perl and Ruby/LISP (link). PowerShell also comes with quite a few pre-defined (read-only) command aliases and functions that come directly from the COMMAND.COM/cmd.exe command shells. The AS/400 Control Language (CL) and SQL (select, where, sort, group) are also frequently mentioned in many early slides and interviews. Maybe we should update the Software infobox template. The Programming language infobox does have the influenced/influenced_by rows. We could also just add this infobox because the article covers both, the command shell itself and the command shell language. Ghettoblaster (talk) 14:02, 28 April 2008 (UTC)
Replacing the infobox would cause a lot of problems, like where to position the screenshot etc etc. Thats why I left it like that. But adding a second infobox may be a good idea. Be bold and add it. With the ref. --soum talk 17:55, 28 April 2008 (UTC)