Diskussion:PowerShell

Hat XP wirklich kein "Get-Process" und "Stop-Process"?

Also ich bin zwar Unixler aber ich glaube unter Windows XP gibt es die Befehle "tasklist" und "taskkill". --77.180.80.62 19:08, 19. Mär. 2008 (CET)

Unter XP läuft Powershell. Also hat XP auch "Get-Process", "STOP-PROCESS" und alle anderen Powershell Befehle. --Robweg (Diskussion) 21:17, 27. Mai 2014 (CEST)

Integration in Vista

Wird dieses Programm nun in Windows Vista enthalten sein? Dieser Artikel sagt ja, der Vista Artikel sagt nein. Was stimmt nun?!? --skicu 09:53, 22. Mai 2006 (CEST)

Es ist nicht in Vista, aber in Windows 7 enthalten.--Frakturfreund 14:35, 24. Aug. 2009 (CEST)

Linux powershell

Es existiert noch eine andere powershell und zwar unter Linux

http://powershell.sourceforge.net/ --princ3 01:00, 13. Okt. 2006 (CEST)

Ich denke nicht, dass es im Artikel wirklich erwähnenswert ist. Die Freigabe der "aktuellen" Version 0.9 liegt mehr als sechs Jahre zurück. [1] Für mich ist es eher eine Karteileiche. Viele Grüße -- Meph666 ^{→ post} 17:36, 21. Nov. 2006 (CET)

Dafür hat die Linux-Shell ca. 120 Befehle 31.17.69.109 23:39, 21. Mär. 2012 (CET)

Arbeitstitel?

oder M$-Buzzwords? Mit Windows NT lernte ich WSH (1.0, 2.0, 5.6.) [2] kennen - von dem MS aber wohl nun nix mehr wissen will. Haben die jetzt mit MSH (AKA PowerShell [3]) wieder mal nen neuen Arbeitstitel vergeben? Mag da mal jemand kurz nen geschichtlichen Abriss der Arbeitstitel von Batch bis Aspen (und was sich da zwischendurch im wesentlichen geändert hat) nachtragen? -- Kyber 20:00, 17. Dez. 2006 (CET)

• Sammlung von Microsoft Codenamen

(nicht signierter Beitrag von 84.140.22.16 (Diskussion) 22:03, 25. Dez. 2006‎ (CET))

Windows Versionen

Also ich habe die PowerShell auf einer Vista Home Version installiert und die ist obwohl es im Artikel steht lauffähig. 85.216.31.56 19:18, 15. Apr. 2007 (CEST)

Kann das nicht bestätigen, offiziell heisst es laut Microsoft: Systemanforderungen: "Unterstützte Betriebssysteme: Windows Vista Business; Windows Vista Enterprise; Windows Vista Ultimate", in der c't habe ich es auch so gelesen, und denen vertraue ich nun mal mehr als einem anonymen Beitrag in der Wikipedia ... Nichts für Ungut und viele Grüße -- Meph666 ^{→ post} 23:01, 15. Apr. 2007 (CEST)

Habe es auch bei mir unter Vista Home Premium am laufen - was ja nach Aussage des Artikels gar nicht geht. Aber so langsam verstehe ich, warum es eine Revolution war, als im Mittelalter aufgeschriebenes Wissen durch Experimente überprüft wurde. Nichts für Ungut und viele Grüße --85.181.41.233 22:28, 29. Jul. 2007 (CEST)

Windows XP home: auch hier ohne Probleme lauffähig.

(nicht signierter Beitrag von 217.237.150.207 (Diskussion) 19:16, 15. Aug. 2007‎ (CEST))

Es ist dasselbe wie z. B. bei Microsofts Virtual PC: Das Ding läuft offiziell nicht auf WinXP Home, in der Praxis hingegen einwandfrei...

(nicht signierter Beitrag von 217.95.119.239 (Diskussion) 01:55, 31. Aug. 2007‎ (CEST))

Leute, die Version 1.0 ist unter Windows PowerShell 1.0 Installation Package for Windows Vista (KB928439) erhältlich, und läuft auf einem aktuell gepatchen Vista Home Premium einwandfrei. Version 1.0 RC2 (welche dummerweise auch bei Google recht weit oben in der Trefferliste erscheint), ist für Vista nur in englischer Sprache erhältlich, und läuft nur auf US-Vista Versionen. Ich habe den Vermerk "läuft nicht unter den Home Versionen" im Text entfernt, und den Downloadlink angepasst. Liebe Grüße, unres_sym

(nicht signierter Beitrag von 84.61.122.65 (Diskussion) 18:41, 26. Sep. 2007‎ (CEST))

Wen interessiert denn bitte schön, ob eine drittklassige Suchmaschine einen Link zu einer uralten Version (RC2) dieser Shell noch findet? Das hat in einer Enzyklopädie doch überhaupt nichts zu suchen. Die PowerShell 1.0 (Final) läuft auf allen Vista Editionen, auf XP und Server 2003 (+Server 2008).

(nicht signierter Beitrag von 78.51.109.42 (Diskussion) 10:18, 27. Sep. 2007‎ (CEST))

Hm, ist Ansichtssache. Wenn du nur aufzeigen willst, wass die PS alles so tolles kann, dann hat diese Information hier auch nichts verloren, richtig. Willst du aber auch etwas über das Drum-herum berichten, dann gehört das schon rein! Gruß, unres_sym

(nicht signierter Beitrag von 192.193.221.201 (Diskussion) 08:22, 10. Okt. 2007‎ (CEST))

CIM / WBEM

Kurze Begründung, warum die Verlinkung der Artikel Web Based Enterprise Management (WBEM) sowie Common Information Model (CIM) durchaus sinnvoll ist: Windows PowerShell greift im Wesentlichen auf vier weitere (ältere) Technologien zurück und verbindet diese innerhalb der Skriptsprache. Dies sind zum einen das .NET-Framework (Erzeugen und Verwenden von Objekt-Instanzen der .NET-Klassen) und herkömmliche native (Kommandozeilen)anwendungen (Win32, DOS). Dazu kommt die Einbindung von COM-Objekten (Component Object Model) und die Unterstützung des offenen Web Based Enterprise Management Standards der DMTF durch Microsofts WMI-Implementation. Die Syntax der PowerShell-Skriptsprache verfügt für die Arbeit mit CIM-Klassen und -Instanzen über spezielle Sprachelemente, die den direkten Zugriff auf das CIM-Verzeichnis ermöglichen. Zusätzlich ist mit Hilfe der eingebauten Implementation der 'CIM Query language' (CQL) der Zugriff auf das CIM-Verzeichnis mit einer SQL-ähnlichen Anfragesprache (WQL) möglich. Ghettoblaster 00:06, 29. Jul. 2008 (CEST)

Hallo Ghettoblaster, danke für die Benutzung der Diskussionsseite. Jedoch denke ich, dass, solange dieser Zusammenhang in keinem der Artikel (weder in PowerShell, noch in CIM, auch nicht in WBEM) erläutert wird, die Verlinkung nicht besonders sinnvoll ist. Sonst erscheint die Verbindung dem Leser völlig aus der Luft gegriffen. Aus meiner Sicht sollte der "Siehe Auch"-Abschnitt nicht als eine Art Todo-Liste zweckentfremdet werden, für Artikelinhalte die noch einzubauen wären. Viele Grüße -- Meph666 ^{→ post} 00:24, 29. Jul. 2008 (CEST)

Wie du meinst. Wollte das bei nächster Gelegenheit aber ohnehin machen. Bin gerade dabei Inhalte aus der englischen Wikipedia (wo ich bisher hauptsächlich tätig war) in die deutsche zu übernehmen. Das ganze hinkt hier leider immer etwas hinterher. Ghettoblaster 00:34, 29. Jul. 2008 (CEST)

Manchmal finde ich, dass es besser ist, wenn die de:WP etwas hinterherhinkt, da bleibt mehr Zeit zum nachdenken ... ;-) so bleiben uns bspw. solche Auswüchse wie en:Gnuzilla erspart. Ohne den deutschen Artikel Namensstreit zwischen Debian und Mozilla, bzw dessen Mitautoren, wäre man in der en:WP vielleicht immer noch der Meinung, dass GNU IceWeasel (jetzt Icecat) und Debians Iceweasel das gleiche wäre; und jedes von den Umbenennungen Iceweasel, Icedove sowie Iceape hätte jeweils einen eigenen Artikel ... Wobei ich die Diskussionskultur dort allerdings gern loben würde, hier kommt man sich ab und zu vor, als ob man ständig gegen eine Horde arroganter besserwisser kämpfen müsste .... Naja ich schweife ein bisschen ab ;-)

Zurück zum Thema, gerne kannst du Inhalte aus der englischen Wikipedia übernehmen, solange du auf Qualität achtest und mit zuverlässigen Quellen arbeitest :-) ... da ist mir vor kurzem auch was blödes passiert ... habe einen Sachverhalt aus der en:WP in einen deutschen Artikel übernommen, bei der Prüfung der Belege stellte es sich allerdings heraus, dass laut dem en-Artikel eine Firma eine Stellungnahme zu einem Kritikpunkt veröffentlicht haben soll, wobei diese vermeintliche Stellungnahme 2 Tage vor der Kritikäußerung abgegeben wurde ... und schon wieder abgeschweift ;-)

Also viel Spass noch und gute Nacht. -- Meph666 ^{→ post} 02:39, 29. Jul. 2008 (CEST)

Nachtrag: unter WP:ASV findet man einige Hinweise, wie man mit assoziativen Verweisen verfahren soll. Gruß -- Meph666 ^{→ post} 08:28, 1. Aug. 2008 (CEST)

Links zu Verlagen

Hallo Leithian, es ist nicht üblich, Links zu den Beschreibungsseiten der Bücher bei den jeweiligen Verlagen aus Literaturlisten zu entfernen. Ich selbst räume gelegentlich Weblinks in Artikeln auf und ich finde man kanns auch übertreiben (Wikipedia-Richtlinien sind kein Selbstzweck). Zudem werden nicht irgendwelche Shops verlinkt sondern eben die Verlagsseiten, die unter anderem auch Auschnitte aus den jeweiligen Büchern, Inhaltsverzeichnisse, Errata und ähnliche weiterführende Informationen enthalten. Ich wüsste keinen Grund warum man diese Informationen dem Leser vorenthalten sollte. Also wäre ich dafür die Verlinkung wiederherzustellen. Viele Grüße -- Meph666 ^{→ post} 00:19, 6. Nov. 2008 (CET)

Hallo Meph666,

ich danke dir zunächst, dass du diese Diskussion eröffnet hast, meinen Standpunkt lege ich auch gerne dar. Weblinks in Artikeln sollen prinzipiell nur vom Feinsten sein und dem Artikel einen wirklichen Mehrwert bieten. Literaturangaben sollen dem Artikelinhalt dienen und die dort befindlichen Informationen belegen bzw. weiterführende Möglichkeiten angeben. Ausschnitte, Inhaltsverzeichnisse oder Errata bieten uns deshalb als Verlinkung keinen Mehrwert, weil es uns um den Artikel geht und nicht um die Bücher, die begleitend angegeben sind. Anders gesagt: wir schreiben nicht den Artikel, um dort die Bücher zu präsentieren, sondern die Bücher belegen den Artikel. Zudem: die verlinkten Seiten sind zwar nicht Shops im Sinne von Amazon, sie sind jedoch vor allem auch dazu da, die Bücher zu bewerben und zu verkaufen, haben somit einen klar kommerziellen Charakter (deshalb WP:WEB Punkt 4). Ich bin noch immer überzeugt, dass die Links draussen bleiben sollten, kann jedoch deine Meinung nun zumindest nachvollziehen: was hälst du daher davon, eine Dritte Meinung einzuholen? Viele Grüße --Leithian ^{Keine Panik!} _Handtuch? 00:29, 6. Nov. 2008 (CET)

Ein paar Fragen habe ich, inwiefern siehst du in den Links, die den Umgang mit weiterführender Literatur wesentlich erleichtern, einen größeren komerziellen Charakter als in einem Weblink zu einem Unternehmen in einem Artikel über dieses Unternehmen? Und inwiefern ist der Verlagslink "schlimmer" als ein automatischer ISBN-Link, oder überhaupt die Auflistung der Publikation? Ich habe die WP:WEB schon oft genug durchgelesen, und finde dass deine Auslegung des Punktes 4 bei Verlagslinks wirklich übertrieben ist. Aus meiner Sicht erschweren deine Änderungen die Arbeit mit weiterführender Literatur. Ich bin der Ansicht dass eine Dritte Meinung erst bei festgefahrenen Diskussionen oder gar bei Konflikten beansprucht werden sollte. Einen solchen erkenne ich hier noch nicht (nicht dass ich einen beschwören wollte, nicht falsch verstehen :-). Erst wenn weder du mich noch ich dich überzeugen konnten, und/oder sich einige andere Benutzer geäußert haben (möglicherweise schauen hier welche rein), ohne dass ein Konsens herbeigeführt wurde, fände ich es angebracht. -- Meph666 ^{→ post} 01:07, 6. Nov. 2008 (CET)

Ich sehe natürlich auch in einem Weblink zu einem Unternehmen einen kommerziellen Charakter, allerdings ist das dann in Ordnung, wenn das Unternehmen a) relevant ist, b) der Artikel nicht nur einen Linkcontainer darstellt und c) der Artikel über das im Weblink betroffene Unternehmen geht. Der Weblink hat in diesem Fall dann nämlich etwas direkt mit dem Artikelthema (sprich: dem Unternehmen) zu tun. Hingegen hat bei den hier betroffenen Verlagslinks der Weblink nicht direkt etwas mit dem Artikelthema zu tun, sondern "nur" mit einem das Artikelthema begleitenden/fortführenden Buch. Etwas anderes wäre es dann, wenn der Artikel über das Buch selbst ginge, dann ist ein Weblink zur Verlagsseite IMHO keine Problem, da On-Topic.

Verstehe ich dich richtig, dass du den Verlagslink hauptsächlich als Service für den Artikelleser siehst? Ich sehe einen größeren Service, wenn ich dem Leser den automatischen ISBN-Link präsentiere, da er dort nicht nur - wie ich finde "einseitig" - Informationen durch den Verlag selbst erhält, sondern die erweiterten Recherchemöglichkeiten. Der Leser soll sich ja nicht zwangsläufig das Buch kaufen müssen (wenn er es doch möchte, so erhält er die Möglichkeiten auch über den ISBN-Link), sondern dieses Buch z.B. in Bibliotheken auffinden können. Ich sehe die Verlagsseite als recht einseitigen Service, den automatischen ISBN-Link hingegen als vielfältigen Service. Zudem: da wir ja bereits den automatischen ISBN-Link haben, sehe ich den zusätzlichen Verlagslink als redundant an, sozusagen doppelt gemoppelt; einer von beiden reicht uns und da sollten wir unseren internen Link gegenüber dem externen Link bevorzugen. Noch anders gesagt: durch einen Link auf den Verlag selbst bevormunden wir den Leser (wir schicken ihn zwangsweise auf die Seite eines Verlagsshops), durch den automatischen ISBN-Link erhalten wir dem Leser die eigene Wahlmöglichkeit und bleiben neutral. Gerade durch den automatischen ISBN-Link erschweren wir zudem nicht die Arbeit mit weiterführender Literatur, wir erleichtern sie vielmehr sogar (auch gegenüber dem Verlagslink), da wir durch ihn eine Vielzahl von Recherchemöglichkeiten (z.B. via KVK oder Bibliotheken) in nicht bevormundender Art anbieten.

Ich hoffe, dass ich meine Meinung nun etwas klarer darstellen konnte. Falls ich dich damit nicht überzeugen konnte, folgender Vorschlag: lass uns doch hier die betroffenen Weblinks einzeln durchgehen, d.h.: du legst mir dar, warum du im jeweiligen Weblink einen wirklichen Mehrwert für den Artikel siehst und ich lege dir dar, warum ich im jeweiligen Weblink keinen wirklichen Mehrwert für den Artikel sehe. Viele Grüße --Leithian ^{Keine Panik!} _Handtuch? 00:50, 7. Nov. 2008 (CET)

Hallo Leithian, danke für deine Ausführungen, ich habe gerade recht viel Streß mit meinem Job, daher bitte ich dich etwas zu warten. Ich wollte ende der Woche ausführlich antworten. Soviel vorab, einzelprüfung der zu verlinkenden Verlagsseiten halte ich für einen guten Kompromiss. Viele Grüße -- Meph666 ^{→ post} 14:06, 10. Nov. 2008 (CET)

Hallo Meph666, klar, kein Problem. Viele Grüße und dir eine möglichst stressfreie Woche :-) --Leithian ^{Keine Panik!} _Handtuch? 16:28, 10. Nov. 2008 (CET)

Kritik?

Die Windows PowerShell wird als grosses "Wunder" gepriesen, überall. Trotzdem hat sie schwerwiegende Mängel.
Es ist beispielsweise unverständlich, warum ich für eine Befehlszeile eine GUI brauche. Die PowerShell lässt sich wegen der Abhängigkeit von .NET nicht ohne das GUI zu laden nutzen. Wozu brauche ich aber eine GUI auf meinem Server?
Ein anderes leidiges Thema ist, dass es keine ssh-Unterstützung gibt. Telnet und RemoteDesktop ist einfach keine gute Idee.
Es gibt noch mehr Probleme. Wenn eines kenntst, so füge es bitte hier an. -- Thomei08 13:51, 15. Sep. 2009 (CEST)

Remotedesktop ist sehr wohl eine gute Idee. --Unrealzocker 22:56, 6. Okt. 2009 (CEST)

Mag sein, aber nur wenn du einen ganzen grafischen Desktop übertragen willst. Für eine Shell (also nur alphanumerisch) ist es ein totaler Overkill. Ich meine es gibt keine Möglichkeit nur die PowerShell zu übertragen. Wie z.B. bash über ssh -- Thomei08 01:03, 17. Okt. 2009 (CEST)

Dem stimme ich voll und ganz zu. Eine Remotedesktopverbindung wegen einer Shell aufzubauen ist ja schon fast eine beleidigung für die Intelligenz der Menschheit. Als ob es keine andere lösung gäbe und auf die noch niemand gekommen wär -.- Nur leider muss man sagen dass sich das nie ändern wird. Windows ist/war immer das System das die Hausfrau aufm Rechner hat und nie wirklich ernsthaft für Server gedacht (urpsrünglich). Und so ein System auf Server umzumurksen und eine Shell zu entwickeln die einfach jetzt Unix-Befehle anstatt die Windows (CMD) eigenen benutzt und sogar eine imitation von MAN anbietet.... Die ganze PowerShell ist und bleibt grundweg fragwürdig. Man sollte es vllt. auch erwähnen das Microsoft es bis heute nicht geschafft hat weder in der CMD, noch in der PowerShell einen Vollbildmodus zu implementieren xD (nicht signierter Beitrag von 80.128.251.133 (Diskussion | Beiträge) 02:28, 28. Okt. 2009 (CET))

Da solltest du dich besser informieren. Windows NT wurde sehr wohl für den Servereinsatz entwickelt. --84.140.200.116 12:26, 18. Jan. 2022 (CET)

"nie wirklich ernsthaft für Server gedacht (urpsrünglich)" NT basiert auf VMS welches sehr wohl als Serversystem gedacht war. Überhaupt ist es ziemlich unsinnig GUI und "Server" auszuschließen. (nicht signierter Beitrag von 91.66.168.146 (Diskussion) 21:23, 5. Sep. 2011 (CEST))

1) In der Server Core-Installation von Windows Server 2008 R2 läßt sich die PowerShell installieren.
2) Mit PowerShell Remoting ist auch eine Remote-Shell verfügbar.--Jo1971 22:40, 29. Nov. 2009 (CET)

Einen Vollbildmodus gab es schon immer bei command.com und cmd.exe und nun auch bei der PowerShell. ALT + RETURN drücken und schon hast du Dein Vollbild. Nur um das mal zu erwähnen. ;-) --Webka 23:06, 11. Jun. 2010 (CEST)

unter meinem windows 7 kommt dabei die meldung: "vollbildmodus wird von diesem system nicht unterstützt". --213.221.250.85 15:14, 19. Okt. 2010 (CEST)

--Änderungserklärung-- --> Gibt man in die WPS folgenden Befehl ein "get-help* | out-file C:\irgendeinetextdatei.txt", dann kann man anhand der Ausgabe und mit einen Editor, der Zeilennummern bereitstellt, erkennen, dass sich in der WPS weit mehr als 129 gmdlets befinden (nicht signierter Beitrag von 91.10.216.241 (Diskussion | Beiträge) 20:44, 15. Feb. 2010 (CET))

"Großes Wunder": Aber die Fähigkeit, Objekte anstelle von Text per Pipeline von einem Prozess zum nächten fließen zu lassen, ist doch genau das, was man sich als Verfasser von Unix-Shellscripten immer gewünscht hat. Nichts kann einem so auf den Senkel gehen, wie die Notwendigkeit, ständig den Stream-Editor "sed" zu bemühen, um sich irgendwelche Infos aus dem Ausgabe-Text irgendwelcher System-Utilities heraus-zu-pulen. Der Artikel ist großartig und informativ. --Ecgbert (Diskussion) 23:36, 6. Dez. 2018 (CET)

"Ab Windows 7 wird die PowerShell in der Version 2.0 vorinstalliert."

Hab hier Win7 Professional - da ist P.S. 1.0 drauf. Scheint also nicht allgemeingültig zu sein. --213.221.250.85 15:15, 19. Okt. 2010 (CEST)

Die Version 2.0 befindet sich im selben Ordner namens 1.0 wie die Version 1.0, aber die Dateiversion lässt ein Windows NT 6.1 alias Windows 7 gleich Windows Server 2008 R2 erkennen, und die PowerShell antwortet auf den Befehl get-host mit ihrer Version.[4] --84.157.211.32 16:59, 30. Aug. 2016 (CEST)

Weblinks

• Inoffizielles PowerShell-Wiki auf Channel 9 - Seite nicht mehr vorhanden ...letzte Version vom 2. September 2010 aus dem Internet Archive hinzugefügt. goodCOFF´^@--93.223.197.193 15:20, 17. Sep. 2011 (CEST)

"Windows 8 wird mit der Version 3.0 der PowerShell geliefert."

Bei meinem Windows 8 (Consumer Preview) ist die WPS nur in Version 1.0 vorhanden (zumindest heißt so der Ordner, system32\Windows PowerShell\v1.0 - eine v2.0 oder v3.0 gibt es nicht). Woher kommt denn die Info mit der 3.0? --DSGalaktos (Diskussion) 16:40, 24. Mär. 2012 (CET)

Bei Windows 7 ist es 2.0. Wenn das keine Rückentwicklung ist... — Weltforce _Disk. 17:53, 24. Mär. 2012 (CET)

Der Ordner heisst immer 1.0, bei allen Versionen. Die wirkliche Version lässt sich über die Eingabe "$psversiontable.psversion.major" in einer Powershellkonsole herausfinden. Noch flotter gehts über die Titelmeldung beim Öffnen einer Powershellkonsole: "Copyright (c) 2006" bedeutet v1.0, "2009" ist 2.0 und "2012" ist 3.0. -- Robweg (Diskussion) 13:37, 28. Mai 2012 (CEST)

Danke schön, aber meine Version 3.0.-1.-1 meldet Copyright 2011. Nur zur Info. --DSGalaktos (Diskussion) 18:49, 28. Mai 2012 (CEST)

Win 8 ist ja auch noch Beta. Noch ist nicht alles so wies beim Release sein wird. --Robweg (Diskussion) 10:28, 1. Jun. 2012 (CEST)

PowerShell als notwendiges Admin-Werkzeug

Mir fehlt vielleicht so der Aspekt beim Überblick, dass man bei einem Exchange Server oder bei der Verwaltung von Windows-Servern angewiesen ist auf die PowerShell und darin dann auch ein entscheidender Zweck und Einsatzbereich liegt. "Windows PowerShell" ...ms technet" ist eine aufgabenbasierte Befehlszeilenshell- und Skriptsprache, die speziell für die Systemverwaltung entwickelt wurde." z.B. http://technet.microsoft.com/de-de/library/bb978526.aspx -- Thomas Österheld (Diskussion) 23:10, 13. Okt. 2014 (CEST)

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.vmware.com/sdk/vitk_win/
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://www.vmware.com/sdk/vitk_win/

– GiftBot (Diskussion) 18:06, 21. Dez. 2015 (CET)

Vorabversion

Version 5 ist keine Vorabversion mehr und im Windows 10 11/15 enthalten. (nicht signierter Beitrag von 91.22.207.186 (Diskussion) 23:55, 1. Jan. 2016 (CET))

cat ist nicht zur Ausgabe einer Datei gedacht

In der Tabelle, in der Powershell-, DOS- und Unix-Befehle verglichen werden, wird die Funktion des UNIX-Befehls "cat" mit "Ausgabe einer Datei" angegeben.

Das stimmt so nicht, "cat" ist eigentlich zum Zusammenfügen von Dateien gedacht.

Siehe auch https://de.wikipedia.org/wiki/Cat_(Unix) --- (nicht signierter Beitrag von 91.206.188.86 (Diskussion) 10:16, 21. Jan. 2016 (CET))

Überarbeitung

Der Artikel hat in meinen Augen eine weitgehende Überarbeitung nötig. PowerShell hat sich in den letzten Jahren stark weiterentwickelt, der Artikel hier jedoch nicht. Ich fange damit an die Einleitung anzupassen. PowerShell ist nicht gleich PowerShell.exe. PowerShell.exe spricht in Windows lediglich die System.Management.Automation-Klasse an. Daher gibt es auch weitere Kommandozeilen (PowerShell ISE, Visual Studio Code und viele weitere greifen lediglich auf die Klasse zurück, d.h. PowerShell kann auch ohne PowerShell.exe genutzt werden).--Overdose (Diskussion) 16:48, 2. Jan. 2017 (CET)

Abschnitt Versionen unvollständig

Bei den Versionen sollte noch hinzugeschrieben, wann diese erschienen und - falls es Einschränkungen diesbezüglich gibt - für welche Betriebssysteme die Version zur Verfügung stand bzw. steht. Ansonsten kann man die im Abschnitt Versionen angegebenen Informationen nicht einordnen. Das ist meines Erachtens wichtiger als alles, was auf der "Diskussionen"-Seite sonst noch so steht.

hinzu kommt, dass die Texte unter Versionen in Futur 1 geschrieben sind. aktuell ist die Version 7. alle anderen versionen sollten in Präteritum stehen also statt "2015 wird in PowerShell 5.0 die Desired State Configuration (DSC) deutlich erweitert und verbessert." besser "2015 wurde in PowerShell 5.0 die Desired State Configuration (DSC) deutlich erweitert und verbessert." und statt "PowerShell 5.1, die aktuelle und voraussichtlich letzte Windows PowerShell Version, erscheint 2016." besser "PowerShell 5.1, die voraussichtlich letzte Windows PowerShell Version der 5er-Reihe, erschien 2016." und statt " Die Entwicklung wird 2016 angekündigt, bevor 2018 das erste GA-Release erscheint." besser Die Entwicklung wurde 2016 angekündigt, bevor 2018 das erste GA-Release erschien." (nicht signierter Beitrag von Binbesser (Diskussion | Beiträge) 11:52, 21. Sep. 2024 (CEST))

Beispiel in cmdlets funktioniert überhaupt nicht, manche sind sogar gefährlich

Wenn man schon Beispiele aufführt, dann sollten die auch funktionieren.
Select-Object -Property Name,Status, Where-Object -Property Status -EQ -Value Stopped
funktioniert jedenfalls nicht. --84.140.200.116 12:24, 18. Jan. 2022 (CET)

Ich habe versucht diesen Abschnitt etwas verständlicher zu machen. Das sind Beispiele für Cmdlets die zum Filtern verwendet werden können, jedoch benötigen sie in der Praxis auch etwas, das sie Filtern können. Beispiele die die Anwendbar (Copy & Paste) sind, sind in den PowerShell#Beispiele --Overdose (Diskussion) 19:46, 7. Apr. 2022 (CEST)

Ergänzung, der Artikel ist auch sonst schlecht geschrieben. Der Hinweis
So ist es möglich, Objekte ...zu konvertieren (Converto-Json)
suggeriert, dass man bspw. bei einer Abfrage mit Get-Location einfach ein Converto-Json anhängen müsse, um eine Ausgabe im JSON Format zu erhalten. Führt man das aber so aus:
Get-Location Converto-Json
dann führt das zu einer Fehlermeldung. Grundsätzlich sollte man vielleicht zuerst einmal angeben, wie man die beiden Dinge miteinander verknüpft, ehe man sie erwähnt. Das Konzept des Verknüpfen sollte also zuerst einmal erwähnt werden. --84.140.200.116 12:34, 18. Jan. 2022 (CET)

Außerdem wäre es hilfreich, wenn man mal ein einfaches Beispiel gibt, wie man in einer Ausgabe von z.B. Get-Process die ausgegebenenen Prozesse nach einem bestimmten String filtert. Das sind nämlich typische Anwendungsszenarien, wenn man mal schnell nach etwas sucht, aber das zu suchende nicht genau vom Namen her kennt.
Get-Process | Where-Object -Property Name -EQ -Value '*calc*'
führt jedenfalls nicht zum gewünschten Ergebnis, obwohl der Windowstaschenrechner gestartet wurde. Wildcards wie '*' scheint die PS wohl nicht zu kennen. --84.140.200.116 12:54, 18. Jan. 2022 (CET)

Dafür gibt es das Beispiel Get-Process p* oder eben Get-Process *calc*. Beispiele für die Anwendung von Where-Object sind ebenfalls vorhanden. Dein Beispiel funktioniert nicht, weil der Operator -EQ keine Wildcards erlaubt. Die PowerShell grundsätzlich aber schon, z.B. mit dem Operator -Like. Das ist auf https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_operators?view=powershell-7.2 gut erklärt, würde aber den Rahmen eines enzyklopädischen Artikels sprengen. --Overdose (Diskussion) 19:53, 7. Apr. 2022 (CEST)

Und dann wurden noch richtig doofe Beispiele im Artikel genannt. Da wären z.B.
Get-Process p* | Stop-Process
Da die Powershell selbst mit p beginnt, wird dieser Process natürlich beendet. Wer denkt sich so einen Müll als Beispiel aus?

Nicht viel anders sieht es mit:
Get-Process | where { $_.WS -gt 10MB } | Stop-Process
aus. Denn die Powershell ist auch 10 MiB groß und wird dann natürlich beendet. Grundsätzlich sollte man keine "Stop-Process" Beispiele in Beispiele liefern. Ich werde mal gucken, ob ich was besseres finde. --84.140.200.116 13:01, 18. Jan. 2022 (CET)

Ich habe nichts besseres gefunden und die gefährlich fahrlässigen Abschnitte daher im Artikel entfernt. --84.140.200.116 13:07, 18. Jan. 2022 (CET)

Kritik: Entstehungsgeschichte / Eingabeaufforderung

Zum Windows Script Host wird behauptet, "es [sic] war anfällig für Missbrauch mittels Computerviren." Das stimmt so einfach nicht. Und es klingt zudem so, als wäre der WSH selbst das Einfalltor für Viren (gewesen). Richtig ist, dass die Möglichkeit, Skripte auszuführen, von Malware ausgenützt wurde und wird. Das ist aber nicht WSH-spezifisch und trifft ebenso auf PowerShell zu.

Ed --~~~~ --92.209.175.230 21:49, 21. Feb. 2023 (CET)

Ich kann auch die Aussage zur Dokumentation ("war nicht leicht zugänglich") nicht nachvollziehen. Sollte sie je zutreffend gewesen sein, so müsste das einen sehr kurzen historischen Zeitabschnitt betreffen. Es gab & gibt zum WSH und den Skriptsprachen umfangreiche Beschreibungen, Artikel und Bücher. Die Aussage zur Eignung/Administration ist missverständlich, denn WSH-Skripte dienen (neben anderen Automatisierungsaufgaben) gerade der Administration, nicht zuletzt durch die Verwendung div. Systemdienste wie WMI und ADSI. (So ist es übrigens auch im WMI-Artikel zu lesen.) Ich habe den Satz daher entfernt.

Ed --84.58.38.211 12:44, 20. Apr. 2023 (CEST)