Talk:PowerShell

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

AmigaOS heritage?[edit]

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)[reply]
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).[reply]
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)[reply]
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)[reply]

Tab completion[edit]

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)[reply]
Maybe "more complete" or just "better" instead of "full"? "Full" is too strong a term, IMO. --tyomitch 08:36, 11 November 2005 (UTC)[reply]
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)[reply]
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)[reply]
PowerShell can complete (nearly) anything: Drives, Folders, Files, Commands, Variables, .NET-Mathods... PowerShell DOES NOT show a tab completion List (by default) so that you can find what you're looking for faster. PowerShell completes with tab to the first cmd(...) (get -> Get-Acl). With the next tab, PS will print the next cmd(...) possible while not rewriting any user-written part of the input string (Get-Acl -> Get-ADObject). With shift-tab you reverse the alphabetical order. Have fun - Jones111

MS or Microsoft[edit]

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)[reply]
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).[reply]
You prefer Microsoft Corporation ??

"Based on UNIX?"[edit]

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)[reply]
COMMAND.COM is based on CP/M, with extra commands added through the versions. CMD.EXE for OS/2 is an extention of COMMAND.COM dos 3 or 4, with some features from unix (pushd, popd, extproc), and some SAA features (REXX /* commands). NT's cmd is based on OS/2's 1.1 version. COMMAND.COM continued to diverge from CMD.EXE (lh, loadhigh). After IBM and Microsoft split, their Command.com continued to diverge (DOS 7 has by IBM, rexx, by Win9x, lock, lfnfor). NT 5 (2000 and later), introduced some extentions to overcome the serious limitations of no access to the CMD environment, but some concerted effort is to make other languages more acceptable through greater accessability to the operating system. --Wendy.krieger (talk) 11:01, 18 May 2010 (UTC)[reply]

Usability- Is it?[edit]

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.
Just because you don't like a company doesn't mean its products aren't notable. — Preceding unsigned comment added by 50.36.225.66 (talk) 19:49, 5 September 2011 (UTC)[reply]

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

A note on viruses[edit]

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

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

... There is no big need to take care against MSH viruses. MSH has a strict execution setting that blocks all unsigned scripts by default. If any Admin changes that setting, it's his or her work to keep the system clean. So I recommed to add a security section (maybe cmparing it with the weaker unix settings ;-)). Have fun Jones111.

Heritage should be included![edit]

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

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


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 (talkcontribs) 06:20, 28 April 2008 (UTC)[reply]

Examples?[edit]

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

Name change[edit]

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

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

WikiBook Link Broken[edit]

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

Leibniz[edit]

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

PowerShell Scripts?[edit]

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

Here:

Community-Submitted Scripts Center

and here:

Windows PowerShell Contest

Job control[edit]

"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)[reply]

Whining[edit]

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 (talkcontribs) 12:13, 22 February 2007

How about... no. —Disavian (talk/contribs) 16:55, 22 February 2007 (UTC)[reply]
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)[reply]
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)[reply]

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

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


I don't know. including testimonials from industry magazines seems to me to violate NPOV. I am not a major wiki editor, though.

Just do it. If they're not appropriate content then edit it. Feel free to also include negative aspects with cites from elsewhere, (like extremetech or haacked or exploit-monday,) you are not limited to MSDN. Put in what you think significant whether that's security flaw reports or limited usage or whatever. Markbassett (talk) 13:29, 17 April 2013 (UTC)[reply]

reception/usage[edit]

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

Central Concepts[edit]

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

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

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

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

Influenced by[edit]

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

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

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


Tcl appears (in yours page) as influence, but isn't in the list "Influenced by" of PowerShell. 200.45.164.99 (talk) 01:47, 16 November 2008 (UTC)[reply]

Fixed. Thanks for pointing that out! Ghettoblaster (talk) 23:06, 23 November 2008 (UTC)[reply]
However, the "ref" given is an offhand comment that doesn't really support the statement. A good ref would point out some syntactic influence, or structural, rather than just a kilroy-was-here-first. Tedickey (talk) 23:19, 23 November 2008 (UTC)[reply]

I started to try to "fix" that first citation then undid it when I realized (a) I wasn't fixing it and (b) it's already a topic of discussion. Sorry. But citing the comment attached to an edit by a Wikipedia user is simply the wrong way to do it. The fact that the userid is Jsnover and that he appears to be the genuine article, the real Jeffrey Snover who created PowerShell, doesn't change things. We can't cite our own edits. Surely Mr. Snover has made an attributable remark in a published interview or even just a personal but identifiable blog. If he hasn't, perhaps he could be encouraged to do that. Or maybe there is other PowerShell documentation available from Microsoft that could serve as a proper citation. This one isn't. Msnicki (talk) 16:58, 8 October 2010 (UTC)[reply]

link in code snippet[edit]

In the example titled "Download a specific RSS feed and show the titles of the 8 most recent entries", there's an icon which I would guess should not be inside a code snippet. But I dunno. 192.114.175.2 (talk) 05:54, 16 July 2008 (UTC)[reply]

Fixed now. Ghettoblaster (talk) 17:28, 16 July 2008 (UTC)[reply]

Why .PS1 ?[edit]

Does the "1" in the .PS1 extension stand for V 1.0 ? Will this change when V 2.0 is released? If it doesn't stand for V 1.0, then why "1" ? - Bevo (talk) 00:29, 21 February 2009 (UTC)[reply]

This blog post from the team explains the versioning: http://blogs.msdn.com/powershell/archive/2007/11/02/ctp-versioning.aspx Ghettoblaster (talk) 09:12, 21 February 2009 (UTC)[reply]

Comparison with "cmd"?[edit]

Maybe it would be worthwhile to add a section comparing it to the standard Windows command shell? I'd add it except I came here to find out... Rafael 01:29, 9 May 2009 (UTC)[reply]

Have a look at the comparison of command shells. Ghettoblaster (talk) 11:36, 9 May 2009 (UTC)[reply]

Reception section[edit]

The Reception section is mainly a set of quotations of opinions of reviewers of this product. Sure, there are citations to the reviews, but they are still just a revewer's opinion. How can this be encyclopedic content? - Bevo (talk) 14:28, 10 May 2009 (UTC)[reply]

Similarly, I was wondering how you write something like this from a neutral point of view and not sound like a sales pitch when the reaction seems to have been overwhelmingly positive (unlike a lot of Microsoft's recent efforts)? O3depleter (talk) 03:53, 25 May 2009 (UTC)[reply]

Broken link in Further Reading section[edit]

This link in the Further Reading section seems to be broken:

Jones, Don. Windows PowerShell: TFM. ISBN 0-9776597-2-0.

--Davidmcb64 (talk) 22:55, 9 September 2009 (UTC)[reply]

And another...

Wilson, Ed. Microsoft Windows PowerShell Step By Step. ISBN 0-7356-2395-3.

--Davidmcb64 (talk) 23:00, 9 September 2009 (UTC)[reply]

PowerShell Community Extensions[edit]

I think there should be mention of PowerShell Community Extensions (PSCX) in the article.

http://www.codeplex.com/Pscx

What do you think?


--Mortense (talk) 19:29, 10 January 2010 (UTC)[reply]

Pash[edit]

I'm not really seeing how the section on Pash is relevant to the article. The project isn't feature complete and hasn't been updated since its initial release in 2008. - 24.211.30.90 (talk) 16:44, 4 December 2010 (UTC)[reply]

I have restarted development on Pash. See the GitHub project . I'm not sure what should go in the Wikipedia page, though. Maybe nothing until I get some press. JBazuzi (talkcontribs) 21:57, 27 March 2013 (UTC)[reply]

"Comparison of cmdlets with similar commands" "bash" column shows non-bash commands[edit]

The "bash" column in the Section "Comparison of cmdlets with similar commands" shows commands, which are not part of bash itself. They are separate commands, from different software packages, like GNU Coreutils for example. Although some external commands are silently replaced by builtin commands of bash, this is not the case with many of those listed in this column, like cat, ls, man, cp, mv, rm, ps and grep for example. So I suggest renaming the column header to something like "UNIX-Style" or something like that, since this seems the easiest way of fixing this. —Preceding unsigned comment added by 95.222.202.219 (talk) 19:01, 12 December 2010 (UTC)[reply]

See also: http://www.gnu.org/software/bash/manual/html_node/Bash-Builtins.html#Bash-Builtins http://www.gnu.org/software/bash/manual/html_node/Bourne-Shell-Builtins.html#Bourne-Shell-Builtins —Preceding unsigned comment added by 95.222.202.219 (talk) 19:12, 12 December 2010 (UTC)[reply]

I agree. That would be good change. Picking up on the title of the the 1984 K&R UNIX Programming Environment (Prentice-Hall) book, I suggest "Unix Environment" or perhaps "Typical Unix Environment", if that works for you and others. Msnicki (talk) 20:03, 12 December 2010 (UTC)[reply]

Perl, C# and Ksh[edit]

From Windows PowerShell in Action by Bruce Payette:

"PowerShell uses the “at” symbol (“@”) in a few places, has $_ as a default variable, and uses “&” as the function call operator. These elements lead people to say that PowerShell looks like Perl. In fact, at one point, we were using Perl as a root language, and these elements stem from the period. Lat- er on, the syntax was changed to align more with C#, but we kept these elements because they worked well. In Perl terminology, they contributed significantly to the “whipupitude quotient” of the language."

"The core PowerShell language is based on the POSIX 1003.2 grammar for the Korn shell. Originally, Perl idioms were appropriated for some of the more advanced con- cepts such as hash tables. However, as the project progressed, it became clear that aligning PowerShell syntax with C# was more appropriate. If nothing else, this would facilitate migrating code between PowerShell and C#. The major value this brings is that PowerShell code can be migrated to C# when necessary for performance improvements, and C# examples can be easily converted to PowerShell. This second point is important, since the more examples you have in a new language, the better off you are."

--174.31.83.131 (talk) 19:42, 12 February 2011 (UTC)[reply]

Version installation requirements[edit]

Not sure how useful this might be, but Microsoft's information on the subject is confusing and abysmal. Seems like Powershell 4 installation requirements are contradicting each other in each page. Could we set MS straight in this article? — Preceding unsigned comment added by 114.31.85.141 (talk) 02:17, 20 September 2013 (UTC)[reply]

Copyright problem removed[edit]

Prior content in this article duplicated one or more previously published sources. The material was copied from: http://technet.microsoft.com/en-us/library/bb978526.aspx. Copied or closely paraphrased material has been rewritten or removed and must not be restored, unless it is duly released under a compatible license. (For more information, please see "using copyrighted works from others" if you are not the copyright holder of this material, or "donating copyrighted materials" if you are.) For legal reasons, we cannot accept copyrighted text or images borrowed from other web sites or published material; such additions will be deleted. Contributors may use copyrighted publications as a source of information, but not as a source of sentences or phrases. Accordingly, the material may be rewritten, but only if it does not infringe on the copyright of the original or plagiarize from that source. Please see our guideline on non-free text for how to properly implement limited quotations of copyrighted text. Wikipedia takes copyright violations very seriously, and persistent violators will be blocked from editing. While we appreciate contributions, we must require all contributors to understand and comply with these policies. Thank you. Codename Lisa (talk) 18:33, 30 November 2013 (UTC)[reply]

cmd exe tee object[edit]

The 'classic' Windows Shell cmd.exe or command.com does not have any ability to do a tee. It does have output redirection, so maybe that should be listed (although it's not a cmdlet so doesn't really belong in this table). It's just wrong to say that the tee process is partially supported, because it's not. peterl (talk) 06:06, 20 December 2013 (UTC)[reply]

Hi. Here is a list of tee functions and their support status in Command Prompt:
Function Status
Can read input from a file instead of keyboard Yes
Can send a copy of output to a file and another to a second command No
Can redirect a command output to a file? Yes
Can duplicate output to a file? No
Can append out to a file? Yes
Can read or write to a variable or array No
Supports LPTx, COMx, AUX or console device files Yes
Supports other file devices No
Looks like enough similarity. Best regards, Codename Lisa (talk) 08:53, 20 December 2013 (UTC)[reply]
P.S. I forgot to mention: I wouldn't have insisted on putting this on a Unix related article but were are discussing PowerShell here, in which the duties of redirection pipes (<, > and >>) are squarely on Tee-Object's shoulder. Best regards, Codename Lisa (talk) 08:57, 20 December 2013 (UTC)[reply]
Hmmm. The description is "Pipe input to a file or variable, then pass the input along the pipeline". So cmd.exe can't do any of this. From the definition of tee (command) "In computing, tee is a command in command-line interpreters (shells) using standard streams which reads standard input and writes it to both standard output and one or more files, effectively duplicating its input." (my emphasis)
Function Status
Can read input from a file instead of keyboard No
Can send a copy of output to a file and another to a second command No
Can redirect a command output to a file? Yes, but that's not in the definition of tee. It's redirection.
Can duplicate output to a file? No
Can append out to a file? Yes, but that's not in the definition of tee. It's redirection.
Can read or write to a variable or array No
Supports LPTx, COMx, AUX or console device files Not that I'm aware of
Supports other file devices No
peterl (talk) 20:35, 22 December 2013 (UTC)[reply]
Hi. Apart from the fact that you forget we are not talking about tee in Unix in spite of my emphasis – we are talking about Tee-Object – why did you say cmd.exe does not support reading input from a file? It does with <. Best regards, Codename Lisa (talk) 16:52, 23 December 2013 (UTC)[reply]
The section starts with "The following table contains a selection of the cmdlets that ship with PowerShell, noting similar commands in other well-known command-line interpreters". cmd.exe does not have any command that performs the same task as Tee-Object (that is, it has nothing that "reads standard input and writes it to both standard output and one or more files"). peterl (talk) 01:19, 27 December 2013 (UTC)[reply]

Similar to Applescript[edit]

Should it be noted that this is essentially Microsoft's version of Applescript, or something along those lines? Pokemonmasterpearl (talk) 17:52, 21 January 2014 (UTC)[reply]

Hi. It depends. Do you have a source?
Best regards,
Codename Lisa (talk) 08:18, 22 January 2014 (UTC)[reply]
If a source is ever found for the OP's claim it'll likely get challenged. AppleScript is a programming language that's more similar to BASIC. PowerShell is a Command-line interface where the command input and output are fully typed objects. --Marc Kupper|talk 21:15, 16 March 2014 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just added archive links to one external link on Windows PowerShell. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 10:53, 22 January 2016 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just added archive links to one external link on Windows PowerShell. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 17:26, 1 March 2016 (UTC)[reply]

Link seems to work. Dhtwiki (talk) 20:11, 1 March 2016 (UTC)[reply]

The name of the Unix shell's command provided by the cURL project[edit]

There's no command called cURL used in Unix shells – it's the name of a computer software project – which provides a command line tool called curl. I have replaced "cURL" with "curl" in the "Comparison of cmdlets with similar commands" section. However, my edit was undone: [3]. 91.224.129.184 (talk) 18:13, 24 April 2016 (UTC)[reply]

Your edit seems appropriate. User:S.Örvarr.S didn't explain their edit. Perhaps the pipe seemed redundant, the two elements identical, except for the case of some letters. Dhtwiki (talk) 23:01, 25 April 2016 (UTC)[reply]

Red Hat release is not yet ready[edit]

Hello

I made a partial revert to Editor-1's edit and I feel I should give an explanation. The edit has added Red Hat Linux to the list of operating system because Microsoft Azure Blog has said so. But apart from the fact that it is the only source that mentions Red Hat (Ars Technica, and PowerShell Blog don't), there is no release or even instruction for Red Hat on the GitHub repo.

Best regards,
Codename Lisa (talk) 06:51, 20 August 2016 (UTC)[reply]

PowerShell installed in all (current) Windows version(?!)[edit]

I Phrase this as a question just in case..

I believe it is a WP:V useful to know fact (I'll not address WP:LEAD reason for revert, for now, "useful" is just my opinion).

I believe the revert of my edit based on WP:DATED may have been hasty. "currently" may possibly be just written out; I meant this similar to the statement "Microsoft's (current[ly supported]) operating systems have a Windows NT kernel". The kernel isn't leaving. Neither is support for batch (.bat) files. The replacement, PowerShell is supported in all now, and has been a replacement for a while now, and not likely to go, now that this much more powerful alternative can be relied on.

To compare, a Linux or Unix-like OS is, likely to have a shell, but not fur sure a window system..: "A typical Linux distribution comprises a Linux kernel, GNU tools and libraries, additional software, documentation, a window system (the most common being the X Window System)" (still this in lead there). comp.arch (talk)

Hello, Comp.arch
Windows PowerShell is NOT installed all currently supported (as of 21 April 2017) Windows operating systems. You already guessed Windows Embedded Standard 2009 and Windows Server 2008 Core. But you forgot Windows PE, Windows Phone and Windows 10 Mobile that are still "currently supported Windows operating systems". Windows PE and Windows 10 Mobile are members of the Windows NT family. I don't know about Windows 10 IoT and Windows 10 Cloud.
Best regards,
Codename Lisa (talk) 20:02, 20 April 2017 (UTC)[reply]
Thanks for the info. People may like to rely in this (or any..) scripting solution (for [desktop] Windows) [to make apps with]; at least I want to (but for obscure purposes..). I like my statements be true.. helpful. If some version is missing PowerShell, I like not be misleading. I know XP can't be relied on, was trying to be helpful with "currently" to exclude it.
I implied non-Core versions (those Core-using people may expect less; have to install), with "full installations".. Is there some sufficient phrase like "full desktop installation" that applies? Yes, probably doesn't apply to IoT or embedded.. and who cares about the mobile solutions? :) At least I don't bother to support..
"Windows Preinstallation Environment [..] is a lightweight version of Windows used for the deployment of PCs, workstations, and servers, or troubleshooting an operating system while it is offline. It is intended to replace MS-DOS boot disks".. not really a concern of mine. comp.arch (talk) 20:25, 20 April 2017 (UTC)[reply]
I don't think you have grasped the problem quite well yet. You are trying to write something that:
  • ...means to be all-encompassing while you simply don't have all-encompassing knowledge
  • ...dates quickly and withers
  • ...is not meaningful anyway, because to know the meaning of what you've written requires comprehensive knowledge of the whole Windows support policy hoopla and memorizing its many dates.
  • ...is of little value when the message is successfully delivered. You are trying to say "if your Windows is supported right now, PowerShell is in it." Sure, this sentence pleases those who enjoy complex word plays but what's the value of that, when the same PowerShell is not in all of them and you have to get the latest version anyway. And since you are out getting things, you might as well get PowerShell for those now-unsupported versions of Windows for which a version of PowerShell is released.
Why don't you switch to something simple and meaningful? e.g., "Starting with Windows Vista and Windows Server 2008, PowerShell was shipped as a Windows component."
Best regards,
Codename Lisa (talk) 08:11, 21 April 2017 (UTC)[reply]
I can live with your "simple and meaningful" phrase. About "you have to get the latest version anyway" isn't true in my case, just knowing that I have any version (I believe the oldest will do), helps. [And if I need newer, I could download it with a PowerShell script. With no good shell, I can't get newer; I want to distribute source source code script that runs on all supported Windows.] comp.arch (talk) 09:39, 21 April 2017 (UTC)[reply]

A few basic commands?[edit]

Hello

I'd like to turn everyone's attention to revision 784099336, where our guest editor (99.245.249.210) replaced "The shell [...] supports a few basic commands" into "The shell [...] currently supports over 200 commands". This is of course, the least controversial of what appears in the diff but I feel this is what gives ground to those more controversial changes. The source given for the claim is ss64.com/nt/ which lists 236 entries.

However, I noticed that among these 236 entries, only 37 are internal commands. The rest are external programs that may or may not come with the shell: ASSOC, CALL, CD, CLS, COLOR, COPY, DATE, DEL, DIR, ECHO, ENDLOCAL, EXIT, FOR, FTYPE, GOTO, IF, MD, MKLINK, MOVE, PATH, PAUSE, POPD, PROMPT, PUSHD, RD, REM, REN, SET, SETLOCAL, SHIFT, START, TIME, TITLE, TYPE, VER, VERIFY, VOL

Hence, I reverted the contribution.

Best regards,
Codename Lisa (talk) 18:28, 7 June 2017 (UTC)[reply]

Yet on tson page there are some external programs for "UNIX shells" like wget and curl, if we want to be consistent I think we also remove these external programs in the comparation and only list internal commands. — Preceding unsigned comment added by 190.96.79.218 (talk)

The so-called changes for clarity[edit]

Hey there. This revision by Mangst made a large number of changes to the article that I reverted wholesale on the account of being wrong. I then proceeded to eliminate the cause of the mistake with this and this change. Now, reverts can be taken very personally, I think an explanation can help.

Mangst wrote:

  • PowerShell (also known as Windows PowerShell and PowerShell Core)’. Oh, God, no. These are three names for three different things. "Windows PowerShell" is a non-free Windows component, "PowerShell Core" is a cross-platform open-source project that also comes with Windows Server 2016. "PowerShell" is an umbrella term for the whole thing. Compare with "Coke", "Diet Coke" and "New Coke".
  • ‘Every version of Microsoft DOS and Microsoft Windows that was released to the public [~snip~]’. Bzzt! Wrong! Windows CE is a "version of Microsoft Windows that was released to the public". It does not have a command prompt or any form or CLI. So are Windows Mobile and Windows Phone.
  • ‘Cmdlets output their results as objects or as collections thereof (including arrays). Wrong again. It is implying that there are different things known as objects and collections in PowerShell. There aren't. There only objects that act like a collection and objects that don't act like a collection. Of course, the prior revision has used the word "collection" in its generic sense, not realizing the word has a programmatic sense too. But you fix should have been the other way around. Damn. Looking at the wrong revision. My mistake.
  • ‘Later, either the entire script or individual functions in the script can be used.’ Well, thanks for telling me that. Up until now, I thought the scripts or their functions are to look at only, because a jumble of source code is as beautiful as a sexy chick! (For Sheldon Cooper: The last sentence was sarcasm.) Okay, the joke's on me. (Ouch! It hurts.) I am removing this sentence!
  • Moving a number of PowerShell 5.1 features into a very short list. Well, that's just unsound judgement.

I admit there might have been good fixes here and there. But in the end, I thought a wholesale reversion, plus two edits, was the correct thing to do. (Technically, if I add two edits on top of a reversions, that's not just a wholesale reversion anymore right? But wait! Nobody cares! Too bad for me.) Sorry for that comment, I was looking at it the wrong way around: There were other poor changes such as changing "pipeline" to "Pipeline" mid-sentence (violation of MOS:CAPS), replacing "or" with "/" (violation of MOS:SLASH), use of "enables" instead of "enable" for "transactions" (grammar error), using "documentation" is an uncountable noun, which is the wrong meaning of it here.

FleetCommand (Speak your mind!) 06:43, 22 October 2017 (UTC)[reply]

Hello, FleetCommand
You struck literally half of your own objections. Did you even see what you reverted? May I suggest you change your username to Goofball Command?
Seriously, though, I am looking at changes between revision 805312503 through 806471369 and I see positive improvements on the whole.
Also, you are supposed to used <ins>...</ins> and <del>...</del> sparringly. Do you mind if I remove one of your tags?
Best regards,
Codename Lisa (talk) 07:36, 22 October 2017 (UTC)[reply]
Hey! Feelings!
If you want to mock at least do it grammatically right. "Goofball Command" is meaningless. "Fleet Goofball" on the other hand, doesn't have this problem; it means a goofy person related to some fleet. Like village idiot.
FleetCommand (Speak your mind!) 09:39, 22 October 2017 (UTC)[reply]
Hi FleetCommand. I did not add or remove any content. My changes were focused on sentence flow and making the content easier to understand. I am only familiar with the basics of how to use PowerShell. If you have a deeper understanding, I hope you can improve the content. Mangst (talk) 21:59, 22 October 2017 (UTC)[reply]

Executable redundant?[edit]

@Codename Lisa: can you please explain your edit summary "When you see redundancy, remove it. Or at least don't inflate it." for your revert of this anon edit? I think it was a good edit, so I have redone it. Thanks. - DVdm (talk) 12:52, 19 January 2018 (UTC)[reply]

@DVdm:
Hi. We once had a teacher who told us an extensive session of teaching people about different types of pistol is not okay in the middle of mentioning Adolf Hitler having shot himself. That's actually an example of our WP:IINFO policy.
Even if you truely believe that enumareting the different executable file names of PowerShell is not an intricate subject that only interest a few hardcore PowerShell fans (who don't need to read this article anyway), the place is not in the middle of discussing how the processes are launched.
Best regards,
Codename Lisa (talk) 13:41, 19 January 2018 (UTC)[reply]
Thanks... but beware. - DVdm (talk) 14:11, 19 January 2018 (UTC)[reply]

attack-tools[edit]

The new section isn't really neutral, since it's largely original research which focuses on PowerShell to the exclusion of other nuisances. To the extent that the material is encyclopedic, it would be more suitable in a separate topic devoted to script-kiddies and their fans TEDickey (talk) 19:27, 25 February 2018 (UTC)[reply]

Hi.
I saw the section too and I reverted its addition outright. It isn't just original research; it is:
  • Factually inaccurate, written by a person who is unfamiliar with the subject matter (See the next list for details.)
  • In violation of our external links policy
  • Self-contradictory. The bottom half of it contradicts the top half, because ... (see the next bullet point)
  • Written from a persepective that does not adhere to WP:NPOV but one that is adjusted to frighten the reader and downplay the security measures introduced to mitigate it. Most importantly, what could happen is misrepresented as what actually happens without assessing its potential.
  • Jargon bombardment. Things are said without explaining what they are and what they do. This is specifically true at the bottom portion of the article. This contributes to the bullet point above.
  • Opinion is often misrepresented as facts, without providing a source for it either, e.g. "Compelling reason" is subjective; who says it? Weasel words are used to reinforce it. e.g. "many" in "Many endpoint security products don't have visibility into PowerShell activity". If there are indeed many such endpoint security products, please list them all, every single one of them. And tell us how you know they don't. "Most organizations are not watching PowerShell activity." "Most" is a weasel word; how do you know that? Did you ask all organizations and discovered most don't? Or is it someone's opinion?
Technical inaccuracies in it include:
  • PowerShell by default does not run scripts. One can, however, download and run a piece of malicious code that runs PowerShell, enables script execution and downloads and runs the intended malicious scripts. But if this happens, malicious code has already passed the security barrier. This malicious code no longer needs PowerShell because it can do virtually anything. And here is the catch: If application whitelisting is in place, PowerShell cannot be used to bypass it because the aforementioned malicious code that would enable script execution in PowerShell cannot run.
  • Many of the reasons given are actually true for every malicious and non-malicious code, because they are not ipso facto a reason to worry. For example, to "Interface with .Net [sic] & Windows APIs [sic]" is always true, except for Universal Windows Platform apps! This includes the malicious code mentioned above. AFAIK, PowerShell cannot access Windows API directly.
  • The claim that "CMD.exe is commonly blocked, though not PowerShell" is patently false; it is quite the opposite.
Generally speaking, when you read a blog post or participate in a conference, and get scared, the thing you must not do is editing Wikipedia.
Best regards,
Codename Lisa (talk) 07:33, 26 February 2018 (UTC)[reply]