Microsoft geeft preview van PowerShell 2.0 vrij

Microsoft heeft Windows PowerShell 2.0 Community Technology Preview uitgebracht. De tweede versie van Powershell biedt onder meer de mogelijkheid tot interactie met een gui.

Een van de opvallende vernieuwingen in de 2.0-editie is de mogelijkheid om met PowerShell Remoting cmdlets en scripts op afstand aan te roepen. Daarbij is het wel noodzakelijk dat PowerShell op zowel de server als de client is geïnstalleerd. Ook kunnen met het PsJob-commando opdrachten op de achtergrond gedraaid worden, zodat de cli beschikbaar blijft voor nieuwe opdrachten. Met ScriptCmdlets geeft Microsoft programmeurs de mogelijkheid om scripts te schrijven in Powershell-script, in plaats van gecompileerde C#- en VB.Net-code.

PowerShell 2.0 kent ook een vierentwintigtal nieuwe Cmdlets. Verder heeft Microsoft een alpha-versie van een grafische shell in de Community Technology Preview verwerkt, waarbij met syntax-highlighting de code leesbaarder wordt gemaakt. Ook kan de gebruiker meerdere tabs openen. Een lange lijst met aanvullingen en verbeteringen is te vinden op het blog van het Windows PowerShell-team. De pre-release van PowerShell 2.0 draait op Windows XP SP2, Windows Server 2003, Windows Vista en Windows Server 2008, waarbij zowel 32- als 64-bits edities ondersteund worden.

Reacties (94)

[Gerco]

Fijn is dat... je moet WS-MAN installeren voor je PS2.0 kan gebruiken. Op zich geen probleem, maar daarvan is voor Windows XP alleen een engelse versie van, die je natuurlijk niet kan installeren op Windows XP NL (ook niet mijn keuze).

Voor Windows Server 2003 is er wel een Nederlandse versie, maar die wil (uiteraard) niet installeren op Windows XP SP2. Mocht iemand die ongelukkig genoeg is om aan een NL XP vast te zitten dit willen uitproberen, bespaar je de moeite.

[Verwijderd]

ooh ik denk al waarom zegt die nou dat de versies niet kloppen.
ik vind het maar een beetje raar,

[Tyrian]

Powershell, ik blijf het een vreemde naam vinden. Een shell, zeker in Microsoft terminologie was altijd een gebruiksvriendelijke, al dan niet grafishe interface boven op de command prompt [DOS]. Zo had je bijvoorbeeld DOSShell en natuurlijk Windows zelf.

Maar nu noemen ze ineens de command prompt zelf een 'shell'. Niet echt consistent. Nou ja, het idee zal wel vanuit de Linux wereld gepikt zijn, want daar heet de command prompt al heel lang Shell.

[SunnieNL]

powershell is nog steeds een shell als vroeger...

vroeger was het echter windows die als shell op ms dos draaide...
nu is het een commandprompt die als shell op windows draait.

[.oisyn]

Dan snap je het woord shell niet. Een shell is gewoon de gebruikersinterface waarmee je bepaalde functionaliteit van het OS kunt gebruiken (zoals het opstarten van programma's). En daarbij maakt het niet uit of dat een text-based shell is, of een GUI. Bash en command.com zijn CLI shells, explorer.exe (!!!) is een grafische shell.

Dat het woord shell in de context van MS-DOS iets grafisch betekent leeft denk ik alleen in jouw hoofd. In config.sys kon je al een andere shell gebruiken door SHELL=<applicatie> toe te voegen, command.com was de default shell (wat aangeeft dat het allesbehalve iets grafisch hoefde te zijn)

[Verwijderd]

Ik vraag me af hoe ze dit beveiligen, want dit soort uitgebreide script-mogelijkheden is natuurlijk vragen om nieuwe virussen.

[wauwwie]

Je kunt je scripts signen met een codesign certificaat en vervolgens de executionpolicy in een "AllSigned"mode zetten. Als dit vanaf een GPO op je werkplek of server afgedwongen wordt kan je met geen mogelijk een script opstarten dat niet gesigned en vertrouwd is.

Je kunt dan nog wel regels intypen, maar dat noem ik dan niet echt een mogelijkheid dat een gebruiker regel voor regel code gaat inkloppen om je kwaadaardige script uit te voeren. Dus geen batchbestandjes meer die met een scheduled task opgestart worden onder een admin account waarbij "zomaar" iemand het script aanpast om er wal "leuks" mee uit te halen.

Het is maar net hoe dicht je Powershell wil zetten.

[Verwijderd]

Niet. Onder linux wemelt het ook niet van de virussen als

#!/usr/bin/bash
rm -rf /

Dat is het voordeel van een multi-user OS: een standaard gebruiker kan het OS niet aantasten.

[Rinzwind]

+ executable flag moet aangezet worden wil je een script kunnen draaien!

[J.J.J. Bokma]

Ik snap wat je wilt zeggen, maar wat je schreef klopt niet. Een script *hoeft* niet executable te zijn om te kunnen draaien.

bash bestand

doet het ook prima.

Verder komen we nu op het welles/nietes pad. Onder Windows hebben gebruikers geen enkel probleem om een zip gekregen via email uit te pakken met bijgeleverd password en dat uit te voeren. Geef zo iemand Linux, stuur 'm vervolgens instructies om op een CLI wat zaken te tikken, iets wat niet geheel ongebruikelijk is bij Linux [1], en je zit met hetzelfde probleem. Waarom dat niet in het wild gebeurd? Het soort mensen dat dit probleemloos doet zit nog niet massaal op Linux, en dat zal ook zeker wel niet op korte termijn gebeuren, en wellicht ook niet op de wat langere termijn (Linux is namelijk nog niet rijp voor de desktop naar mijn mening, ondanks dat we dat al jaren lang elk jaar opnieuw moeten lezen).


[1] Overigens vind ik dat er niks mis is met een aantal opdrachtregels, bijvoorbeeld op een blog gepost, om een resultaat te verkrijgen. Vaak is het eenvoudiger te schrijven en te lezen (en uit te voeren), dan een aantal screendumps met instructies als: klik op dit, open menu dat, dubbel klik op dat, dan komt er een nieuw venster, klik daarin op, etc. Alleen jammer dat in een aantal gevallen onder Linux (mijn ervaring) vaak dat de enige (bekende) manier is. En er ontwikkelaars zijn die vinden dat het prima zo is.

[YopY]

Tsja, da's het voordeel en het nadeel van Linux. Ikzelf heb er ook wel mee gespeeld, en vaak kopieerde / plakte ik eenvoudigweg een console commando om maar iets uit te voeren. Het grote voordeel en grote nadeel van command line interfaces (tenminste, de 'ongelimiteerden') is hun kracht; met een enkel commando kun je alle bestanden die eindigen op .temp (oid) verwijderen, maar een typfout en je verwijdert alle bestanden.

Nu is het (gelukkig?) in Windows zo dat je een bestand die in gebruik is niet zomaar kunt verwijderen, en dus de verwijder-opdracht stopt zodra het zo'n bestand vind. Daarnaast is het in Unix zo dat er een goed permissie systeem zit op bestanden. Maar ja, daar tegenover is 'sudo' zo ingetypt.

[J.J.J. Bokma]

[Linux] ... met een enkel commando kun je alle bestanden die eindigen op .temp (oid) verwijderen

Niets stopt je om een alias te maken die deze bestanden niet wist, maar naar een vuilnisbak directory verplaatst.

Daarnaast is het in Unix zo dat er een goed permissie systeem zit op bestanden

Dat is in Windows ook aanwezig, zelfs fijner (als in nauwkeuriger) dan wat jij wellicht bedoelt (het chmod gebeuren). Natuurlijk is er voor *nix ook zoiets als wat op NTFS aanwezig is. Wat jammer is, is dat veel te veel mensen op Windows domweg altijd met admin rechten werkt (vaak door gebrek aan kennis).

daar tegenover is 'sudo' zo ingetypt

Uit mijn hoofd: als met chmod de rechten van de directory waar jij bestanden uit wilt wissen zo staan dat je niet mag schrijven (naar de directory), helpt sudo je ook niet met rm. Natuurlijk kan je wel met chmod die rechten van de directory aanpassen.

[Belial_666]

Is er een verschil tussen het achteraf toevoegen van CLI en het vanaf het begin af aan intergreren van Bash
oftwel loopt de CLI niet altijd achter de feiten aan omdat het er acheraf aan toegevoegd is ?

[user109731]

Wat de CLI in Unix (nouja, ik ken alleen Linux en een beetje BSD) zo fijn maakt is dat heel het OS er omheen opgebouwd is. Unix systemen gebruiken bijvoorbeeld pseudo-filesystems, dit zorgt ervoor dat je de standaard Unix commando's, editors, etc. kunt gebruiken om systeeminformatie en dergelijke op te vragen. Het gedraagt zich als een bestandssysteem, maar het is het niet. De configbestanden en logbestanden van de meeste (GUI-) software is ook gewoon plaintext, wat het erg handig maakt voor scripts of CLI commando's.

Denk ook aan de Virtuele consoles, en de loskoppeling van GUI en CLI. Start je op in recovery mode (zonder GUI, etc.), dan kom je in precies zo'n shell terecht als degene in je grafische omgeving, en kun je besluiten om de GUI 'op te starten'. Of als de GUI hangt of crasht, dan switch je naar een andere console en herstart je de GUI.

De Unix shells zijn imho dus zo krachtig dankzij de integratie, de vele opzich eenvoudige commando's die samen erg sterk zijn, en de alles-is-een-bestand filosofie... Ik denk dat het moeilijk is om dat er achteraf in te bouwen.

[Reactie gewijzigd door user109731 op 22 juli 2024 13:47]

[Verwijderd]

En waarom denk je dat MS powershell ontwikkeld.
Het register onder windows is met powershell ook te benaderen als bestandsysteem....

[daft_dutch]

Maar nog steeds te laat.
Heb je zo dadelijk een prima shell maar dan nog. Heb je wel applicaties nodig die er mee overweg kunnen. MS apps hebben slechte tot geen cli info.
iexplorer /? komt uit op een malofide internet pagina

[wauwwie]

Je hebt gelijk over slechte CLI info in ms apps. Echter zjin deze apps meestal interactieve apps. En hier kun je nou eenmaal slecht met een cli omgaan, je zou elke keer IE starten bij een nieuwe opdracht.

Vanuit PowerShell kun je wel naar deze comobjecten connecten en ze zo bedienen.
Met de opdracht "$ie = New-Object -comobject internetexplorer.application" start IE en vervolgens kun je met "$ie | get-member" zien welke opdrachten je kan uitvoeren op IE (start, stop, navigate, e.d.). dit werkt ook met Word, Excel en andere programma's die zich als een comobject presenteren.

Natuurlijk kan dit ook vanuit .vbs, maar PowerShell is hier veel duidelijker in wat het scripten veel makkelijker en sneller maakt.

Alles wat op .Net 2.0 en WMI draait kan je bedienen vanuit PowerShell.

[user109731]

Het register onder windows is met powershell ook te benaderen als bestandsysteem....

Maar kun je ook vanuit de PowerShell "explorer HKLM:\" doen, zodat je met de Verkenner door het register kunt browsen? Dat bedoelde ik met integratie en eenvoud...

[Abom]

Jij hebt het nu over functionaliteit van explorer...wat heeft dat met powershell te maken?

Ja ik begrijp dat je wilt dat je door het gebruik van powershell, andere applicaties enabled om b.v. door het registry te browsen, vind het maar een vreemd idee...en zie er het nut niet van.

Het is toch ook niet zo dat door het gebruik van BASH of een andere shell, vi uitgebreider wordt?

[Reactie gewijzigd door Abom op 22 juli 2024 13:47]

[user109731]

Wat ik bedoelde was dat in Unix-based OS'en, bijna alles een bestand is, en dus ook door elk programma benaderd kan worden. Wil MS met de PowerShell een goede Bash-tegenhanger maken, dan moeten ze *dat* denk ik ook aanpakken.

Waarom is HKLM:\ in de PowerShell wel beschikbaar, maar niet systemwide in explorer? /proc kan ik toch ook gewoon in vi, gedit en nautilus benaderen?

[Abom]

Ik begrijp wel wat je bedoeld. Echter begrijp ik niet waarom jij van deze tool verwacht dat het de 'basis' van Windows vernieuwd.

Ik vraag me dan weer af waarom je wilt dat alles als filesysteem beschikbaar moet zijn. Dat het fijn werkt voor jou, wil nog niet zeggen dat een goede optie voor Windows is.

Sowieso zie ik niet in waarom de basis van Windows aangepast moet worden om PowerShell goed te maken. PowerShell heeft al de kracht om zo goed als alles van je OS te beheren, zonder dat alles als een filesysteem bereikbaar is.

[user109731]

Sowieso zie ik niet in waarom de basis van Windows aangepast moet worden om PowerShell goed te maken. PowerShell heeft al de kracht om zo goed als alles van je OS te beheren, zonder dat alles als een filesysteem bereikbaar is.

Misschien heb je gelijk, maar het grote voordeel van alles-als-bestand is denk ik dat je bestaande tools er voor kunt gebruiken, en dat het veel eenvoudiger is (1 set commando's). Stel, je wilt bijvoorbeeld het register backuppen, dan kun je daar een speciale register-backup-tool voor pakken, maar als het een filesystem is kun je dat gewoon zippen. Denk ook aan grep/sed e.d. (om bestanden te doorzoeken) Het is leuk dat je nu cd, dir e.d. kan gebruiken om er doorheen te navigeren, maar als filesystem kun je alle tools, dus ook de (grafische) zoektools, beheertools, etc. erop loslaten.

Programmeurs kunnen in plaats van een CreateRegistryKey ofzo dan ook simpelweg een normaal bestand aanmaken. En voor filesystems bestaat al een rechtensysteem. Maar goed, misschien denk ik te simpel

[Reactie gewijzigd door user109731 op 22 juli 2024 13:47]

[SED]

maar het registry is feitelijk al een bestand dat je kunt zippen. daarnaast zit er in het registry zelfs een rechtensysteem. Daarnaast kun je op de files van het registry rechten zetten. Kortom, alles wat jij wenst is al lang gedaan in Windows.
Het inlezen van een reg key kan gewoon door het aanmaken van een bestandje met daarin de gewenste waarde en als je de rechten hebt het inlezen daarvan.

Ken jij windows eigenlijk wel?

[J.J.J. Bokma]

Niemand stopt je om een driver te schrijven die precies dat doet. Het klopt dat in UNIX het min of meer een filosofie is: alles is een bestand (wat niet altijd voordelen heeft overigens). Met Windows is dat niet het geval, en is er dus minder vraag naar. Maar niets stopt een enthousiaste ontwikkelaar om een driver te maken die het mogelijk maakt om het register gewoon via een drive R: te benaderen :-).

[YopY]

dan hoop ik wel dat ze de benamingen van de verschillende mappen iets eenvoudiger maken, of dat je met wildcards can browsen .

[Jaap-Jan]

PowerShell 2.0 ondersteund nog geen tab completion, aldus dit blog op MSDN.

Met tab completion kun je bijvoorbeeld 'HKEY_L' typen en door op tab te drukken wordt dat dan aangevuld tot 'HKEY_LOCAL_MACHINE'.

Dus voorlopig wens ik je veel plezier om een waarde te verwijderen uit HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/Run.

[Reactie gewijzigd door Jaap-Jan op 22 juli 2024 13:47]

[Verwijderd]

Of wat dacht je van die fijne GUIDs, ook lastig.

[SED]

dan start je regedit po en voila weg is die waarde

Zit je nu moeilijk te doen om het moeilijk doen?

[bitflusher]

ligt het aan mij of is bash een CLI (command line interface)??

[afterburn]

bash (en elke andere shell, prefereer zelf ksh) is ook maar een losstaand programma wat apart wordt opgestart nadat je inlogt. En als je vanuit X werkt, wordt het gestart als je een terminal window opent. Dus het is niet een kwestie van integratie en werkt feitelijk hetzelfde als de Windows cli en powershell.

[silentsnake]

Goeie zaak. Als ze nou nog de GUI van een Windows Server optioneel maken tijdens de installatie ben ik blij. Ik hoef voor een webserver echt geen GUI op m'n server te hebben staan, om maar een voorbeeld te noemen. Misschien kan Microsoft nog een voorbeeld nemen aan Tobi Oetiker & Friends...

[mashell]

Ik hoef voor een webserver echt geen GUI op m'n server te hebben staan

In de jaren 90 blijven hangen? Het is 2007, ook sysadmins doen tegenwoordig klikker de klik ipv typer de typ. Bovendien is geheugen zo goedkoop en zijn er zoveel processing power dat het voor de server efficiency ook niet meer uitmaakt.

[YopY]

Het gaat om het principe: waarom een GUI als je hem echt niet nodig hebt? Mensen met ervaring (sowieso in de *nix wereld) geven bijna zonder na te denken al de voorkeur aan een CLI, simpelweg omdat je dan geen onnodige dingen op je scherm hebt, en omdat je veel meer controle hebt over je systeem.

Onthoudt wel dat indien je iets wilt beheren in een CLI je er een configuratieprogramma of in ieder geval een GUI voor moet schrijven - bij CLI programma's voer je een commando in of bewerk je een bestand en klaar is het.

Ontwikkelaars schrijven ook liever programma's voor de command line indien een GUI niet verplicht is. Bespaart veel tijd.

[J.J.J. Bokma]

Ik mag mij zeker een mens met ervaring noemen, maar voor diverse taken geef ik echt de voorkeur aan een GUI. Het "op een server hoort geen GUI" is een beetje een soort ouderwets denken. Aan de ene kant begrijp ik het best, je wilt zo min mogelijk op een server hebben draaien, omdat je een dedicated systeem wilt hebben. Maar op een beetje server moet tegenwoordig al zo veel extra zooi geinstalleerd worden, dat een GUI eigenlijk in het niet valt bij al die extra zooi. Kijk maar eens wat er allemaal op een GNU/Linux server mee moet komen... En qua veiligheid en zo, ik vertrouw menig GUI boven dingen zoals PHP en webapplicaties geschreven in PHP.

Een GUI over een SSH verbinding vertrouw ik ook heel veel meer dan een PHP iets in een browser, zelfs als dat laatste SHTTP gebruikt.

Tenslotte, als ontwikkelaar, de belangrijkste reden waarom ik graag CLI programma's schrijf is dat de meeste gebruikers van die programma's er niet gek van op kijken als zo'n programma stopt met "Geen rechten om deze operatie uit te voeren op bestand 'naam.txt'". In een GUI is dat wat minder makkelijk, omdat je het programma er niet vrolijk mee uit kan laten knallen, en vaak ook een oplossing moet aanbieden die de gebruiker snapt. En dan heb ik het er nog niet over dat zo'n foutmelding window niet altijd de hele applicatie lam mag leggen tot de gebruiker klikkerdieklik heeft gedaan...

Het bespaart dus inderdaad tijd, maar dat levert vaak ook wel erg knullige software op, die niet iedereen zomaar even kan gebruiken. Dus een leuke tijdsbesparing (en kosten besparing) voor de ontwikkelaar. De vraag is of dat altijd eerlijk is om de gebruiker vaak dan maar met een iets lastiger te gebruiken applicatie op te zadelen.

[silentsnake]

Daar gaat het niet om. Ik ben prima aan een CLI gewend en ik hoef echt niet in m'n GUI een wizard om een website aan te maken ala IIS. Sowieso vind ik IIS niet echt praktisch kwa configuratie. Ik zit altijd in het verkeerde tabblad of ik vergeet onder welk tabblad wat nou precies stond. Config files kunnen ook zo z'n nadelen hebben, maar als je weet hoe je applicatie een beetje werkt valt dat ook wel mee. Sowieso lijkt het mij handig dat je wat van je applicatie weet als je het moet beheren

Maar goed, het is maar net wat je gewend bent denk ik. Ik als Unix sysadmin snap niet waarom je voor alles een wizard moet hebben, en een Windows admin snapt waarschijnlijk niet waarom je ala 2007 nog zit te tikken, zoals je zelf al aangeeft

[Verwijderd]

Sowieso vind ik IIS niet echt praktisch kwa configuratie. Ik zit altijd in het verkeerde tabblad of ik vergeet onder welk tabblad wat nou precies stond.

Als je weet hoe je applicatie een beetje werkt valt dat ook wel mee.

Sowieso lijkt het mij handig dat je wat van je applicatie weet als je het moet beheren.

Dus: Als je IIS wilt beheren lijkt het jezelf handig dat je wat van de applicatie weet.. zo te zien weet je er niks van.

[SirBlade]

Een goede "applicatie" kan je op meerdere manieren beheren, dus zowel via een uitgebreide GUI, een simpele wizard (die overigens ook in textmode kan zijn, denk bv aan de oude installers voor linux), commandline-tools, scripting-interfaces of rechtstreeks via configfiles in een teksteditor.

BV een AD waar je user aan toe kan voegen via de MMC, via commandlinetools zoals DSADD, via ADSI voor scripts. MS levert overigens standaard een behoorlijke hoeveelheid commandline tools mee om allerlei zaken mee in te stellen of op te vragen, maar niemand lijkt die te kennen.

[Pietervs]

Het is 2007, ook sysadmins doen tegenwoordig klikker de klik ipv typer de typ.
Waarmee je perfect aangeeft dat er toch wat schort aan de opleidingen van de huidige sysadmins...

Bovendien is geheugen zo goedkoop en zijn er zoveel processing power dat het voor de server efficiency ook niet meer uitmaakt.
Geheugen- en processing power is geen reden om overbodige zooi te installeren. Als je een lege plank hebt in je kast ren je toch ook niet naar de winkel om die plank maar zo snel mogelijk te vullen?
Waarom extra risico's lopen met betrekking tot drivers voor zaken die je niet nodig hebt? Waarom extra beheerstaken op je nemen (want die drivers moeten ook regelmatig geupdate worden)? Waarom inboeten in snelheid (zelfs met de snelste processoren en geheugens: alleen een shell zal sneller laden dan een gui)?

ik ben het dus meer eens met YopY dan met JJJ Bokma...

[SED]

wat schort er aan de opleiding.. het feit dat ze met hun tijd meegaan? dat ze weigeren te blijven hangen in verouderde benaderingen?
Moet iedere sysadmin dan een cursus geschiedenis gaan volgen om te snappen waarom er nog mensen schijnen te zijn die liever hun typevaardigheden op peil houden dan een programma configureren?


Een CLI geeft je alleen de info die je opvroeg. Een GUI ( tenminste een goede dan) geeft bijvoorbeeld ook statusinfo over instellingen. Dat wil zeggen dat je in een GUI vaak meteen ziet waar het rpobleem zit terwijl een typemiep nog steeds aan het typen is om te bedenken wat hij allemaal op moet vragen om te controleren.

Natuurlijk heeft een cli soms de voorkeur, vandaar ook powershell en dergelijke, maar een GUI geeft vele malen meer info die je systeem veiliger en stabieler kan maken. In ieder geval het beheer beter en simpeler maakt.

[Rinzwind]

Om de "server core" reacties voor te zijn: asp.net heeft het .net framework nodig en laat dat nu net een gui vereisen. Raar maar waar.

[Laurens-R]

Ehrm... nee?

Als het om de install gaat niet perse (Windows Installer kan je volledig aansturen via een CLI). Om te configureren ook niet (ook daarvoor heeft .net CLI tools aan boord).

Er zit een GUI component in, dat is waar (Windows Forms en XAML bv), maar in feite kan het prima zonder GUI werken hoor.

Anders zouden .net console programma's ook niet mogelijk zijn.

Als je kijkt naar ASP.Net: Deze kan je ook prima via de console tools van IIS configureren (hoewel een tikkie omslachtig). Maar dit is eerder een beperking van IIS dan van .net

[Reactie gewijzigd door Laurens-R op 22 juli 2024 13:47]

[Rinzwind]

Server Core bevat toch echt geen .NET runtime en de afhankelijkheden van de GUI zijn daar de oorzaak van. Dat maakt ook gelijk PowerShell onmogelijk op Server Core...

[Reactie gewijzigd door Rinzwind op 22 juli 2024 13:47]

[Laurens-R]

Ik heb me even op het onderwerp ingelezen. Het heeft te maken met het feit dat het framework gelinked is met depencies (oftewel DLL libraries e.d.) die niet meegeinstalleerd worden met Server Core. Niet alleen de GUI libraries, maar ook de libraries die gebruikt workt in andere namespaces (naast Windows.Forms e.d.).

MS heeft blijkbaar een probleempje met het scheiden van de diverse componenten in het framework (wat ik een beetje vreemd vind omdat alles al zo gescheiden is opgebouwd - Bijna elke namespace heeft zowat z'n eigen dll).

[Shal-Ziar]

Power shell is dus een soort server prog?

[cyspoz]

Nee, het is een Command Line Interface waarmee je middels scripts en commando's met het systeem kan communiceren.
Vergelijk het een beetje met dos, alleen is PowerShell veel uitgebreider en krachtiger. Het bied veel meer geavanceerde functies.

[i-chat]

het enige wat ik me hier dan weer afvraag, waarom nu WEER een scriptlet gedoe, terweil er al zo veel zijn...

ik noem een VBscript Ansci C of zelfs PERL of wat dacht je van 't relatief nieuwe en goed uitbreidbare maar wel heel erg prettige (vind ik) Lua

[Adion]

Je vraagt je af waarom weer een nieuwe scripttaal, en daarna geef je zelf aan dat je een relatief nieuwe taal erg prettig vindt werken. Blijkbaar waren er dus ook voor jou nog redenen om niet tevreden te zijn met perl bijvoorbeeld, dus is het toch logisch dat ook microsoft misschien nog verbeteringen ziet?

[J.J.J. Bokma]

of zelfs PERL

Je bedoelt vast Perl (wat overigens geen acronym is). Zelf ben ik nogal een heftige Perl gebruiker, maar toch zijn er dingen die ik soms gewoon nog in bat bestandjes doe, ook omdat niet iedereen Perl wil of kan installeren.

PowerShell zal ook niet iedereen hebben draaien, maar wellicht in de toekomst wel. Ik wil zeker (meer) tijd in het bekijken van PowerShell steken, en dat als Perl programmeur.

@Adion: het is ook geen perl (als programmeertaal), perl is de naam van een programma dat in staat is om een programma geschreven in Perl uit te voeren.

[_Squatt_]

Practical Extraction and Report Language?

[Verwijderd]

@Squatt:

Betekenissen van "P.E.R.L." zijn later verzonnen. Oorspronkelijk is het geen afkorting.

[narcan]

Omdat user-based interprocess communication wel gewenst is op windows, zeker als je met systeem objecten en applicaties kan communiceren. Dit kon wel beperkt in bepaalde applicaties (suites), maar dit is veel beter als je meer controle wilt over je systeem.

[Verwijderd]

Neuh, tis een vernieuwde 'power' commandprompt voor windows

[RuddyMysterious]

Zou dit dan menig criticaster over de streep kunnen halen inzake vrijheid in het veranderen van settings in het OS?

[Bigs]

PowerShell voegt geen nieuwe functies toe aan de kern van Windows, het maakt ze alleen makkelijker toegankelijk (makkelijk WMI benaderen vanaf de commandline etc.). Overigens is Windows imo best aardig te tweaken.

[RuddyMysterious]

Dat wel, maar dan meestal enkel via GUI's, wat sommigen niet kunnen appreciëren.

[Pietervs]

En terecht: waarom moet je op een serverconsole bijvoorbeeld Patience kunnen spelen? Het is een server: moet dus gewoon in dienst staan van de gebruikers. Alles wat je ermee moet kunnen doen moet je gewoon via een shell kunnen, scheelt een hoop drivers en onnodig geheugengebruik...

[SED]

dat zegt meer over de installatievaardigheden van de systeembeheerder. Wie gaat die spelletjes installeren op een server. Standaard staat dat allemaal uit.
Als jij kennelijk de keuze wilt om spelletjes op een server te installeren dan heb je die bij Windows. Keuzevrijheid dus

[YopY]

Alleen indien PowerShell ook echt vrijheid geeft. Ik zou het persoonlijk het mooiste vinden als je PowerShell gewoon buiten Windows kunt gebruiken, zodanig dat het een besturingssysteem op zichzelf wordt.

[Verwijderd]

Een 32bits MS-DOS dus? Wat shciet je d'r mee op, als er toch al plannen zijn om Windows Server te voorzien van een versie waar je zonder GUI, dus met alleen powershell, kan runnen?

[FragNeck]

Dit is dus absoluut niet te vergelijken met DOS he.

[PeaceNlove]

Wel waar! Ze hebben allebei witte letters op een zwarte achtergrond in een simpel edoch leesbaar lettertype

[Neko Koneko]

PowerShell heeft een donkerblauwe achtergrond

[J.J.J. Bokma]

Bij een Command prompt venster kan je zowel het font als de achtergrondkleur (en natuurlijk de kleur van de tekst) zelf instellen (Eigenschappen).

Ik gebruik zelf Lucida Console als font.

Voor mensen die nogal veel met de cli werken, en tabs handig vinden, kan ik aanraden om eens naar Console 2 te kijken (Marko Bozikovic). Ik open op een dag meestal 1x console, en heb dan 5 "Command prompts" onder 5 tabs beschikbaar, elk al in hun eigen directory.

[dassenhanger]

Ik gebruik Cygwin al, en ik heb laatst een tijdje Powershell geprobeerd. Daar kon ik toch niet aan wennen. Het kan alles wat ik wil, maar je moet weer helemaal opnieuw beginnen met alle statements leren, en ik had de indruk dat je meer moet typen. Ik weet niet meer hoe het precies ging, maar het equivalent van 'ls -1' bleek behoorlijk lang te zijn toen ik het eenmaal had uitgevogeld. Wat ik wel cool vind is het open-source uitbreidingspakket dat je kan downloaden. Daarin zit bijv de feature om te pipen naar clipboard.

[bavanandel]

Een probleem waar ik een tijd mee geworsteld heb (op m'n werk) zijn lange full path names. De standaard Windows include files (windows.h) hebben MAX_PATH = 260 (dat is inclusief het "C:\" etc). Het vervelende is dat dit niet een restrictie is van NTFS (die gaat tot over de 32000), maar puur van de executables die deze standaardwaarde overgenomen hebben, waaronder cmd.exe, explorer.exe, en (helaas) ook PowerShell 1.0 heeft dit probleem.

Het kan dus zo zijn dat je bestanden hebt staan (en ook kunt zien) waar je vervolgens helemaal niks meer mee kan met de standaard tools. Openen gaat niet, verwijderen gaat niet, rechten aanpassen ook niet en renamen is vaak ook onmogelijk. Dat is wel weer te omzeilen door een substation aan te maken (subst x: <pad wat nog net toegankelijk is>) maar ook hier houdt het een keer op natuurlijk. Best lastig als mensen op je server bestanden met erg lange namen (maar nog wel toegankelijk) opslaan waar je vervolgens via het UNC-pad niet meer bij kunt...

Ik heb momenteel geen behoefte aan PowerShell 2.0 dus ik ga het niet zelf uittesten, maar uit de blogs van Microsoft met daarin de veranderingen die zijn doorgevoerd kan ik niet opmaken dat deze belemmering omvergeworpen is. Ik vrees van niet...