Microsoft vervangt opdrachtprompt door PowerShell in Windows 10-preview

Microsoft heeft de opdrachtprompt op bepaalde plaatsen vervangen voor PowerShell in de meest recente versie van zijn Windows 10 Insider-build. Bijvoorbeeld in het contextmenu dat verschijnt bij een shift-rechtsklik in de file explorer.

Microsoft schrijft dat het de beste 'command line experience' aan zijn gebruikers wil bieden en dat het er daarom voor gekozen heeft de opdrachtprompt op bepaalde plekken te vervangen. Daardoor is nu alleen PowerShell te selecteren bij een rechtsklik op de startknop of via de corresponderende sneltoetscombinatie met Windows-toets en 'x'. Gebruikers kunnen er alsnog voor kiezen om bij de oude opdrachtprompt te blijven door dit aan te geven in de personalisatie-instellingen, aldus Microsoft.

Daardoor verdwijnt de opdrachtprompt niet in zijn geheel, maar verlegt Microsoft duidelijk de nadruk op het nieuwere alternatief. PowerShell biedt een groter aantal functies dan de opdrachtprompt, waaronder het gebruik van zogenaamde 'cmdlets'. Deze commando's geven toegang tot verschillende acties.

Een andere verandering in de Insider-build is de mogelijkheid om onbeveiligde epub-bestanden in de Edge-browser te lezen. Gebruikers kunnen daarbij kiezen uit drie visuele thema's. Bovendien is er een preview-versie van Paint 3D in de build beschikbaar. Deze nieuwe versie van Paint werd eind oktober door Microsoft aangekondigd als onderdeel van de Creators Update, die begin 2017 moet uitkomen. De bijbehorende Remix 3D-community, waar gebruikers 3d-objecten kunnen uitwisselen, is volgens Microsoft nu ook beschikbaar in Nederland en België.

      Opdrachtprompt en PowerShell

Reacties (111)

De optie om de commandline te vervangen door Powershell bij bijvoorbeeld het rechtsklikken op de startknop was er al een tijdje. Ik denk dat het een slimme zet is om dit verder door te voeren. Zo kun je de bekende commando's blijven gebruiken maar zijn gelijk de Powershell commandlets tot je beschikking.

Je ziet dat het duidelijk de visie van Microsoft is om Powershell meer en meer een prominente plaats te geven. Binnen de zakelijke omgeving is dit al langere tijd duidelijk (zie bijvoorbeeld Exchange die geheel met Powershell bestuurd wordt). De stap naar de desktop is een logische.

[Reactie gewijzigd door Bor op 18 november 2016 19:47]

Ik heb hiervoor regedit hacks gezien, er is niet toevallig een toggle momenteel ergens right?

Ik juich deze move alleen maar aan, PowerShell is eindelijk een soort fatsoenlijke shell, en heeft volgens mij nagenoeg geen nadelen. (Misschien dat mensen die met legacy dingen werken wel nadelen weten)

Als ik even snel basale commando's wil uitvoeren, zoals ipconfig, dan merk ik wel degelijk een nadeel: PowerShell heeft vaak een startlag van een seconden of wat. Ik heb dit op meerdere servers met verschillende OS'en gemerkt.

Dat ervaar ik inderdaad ook als nadeel. Zou liever 'get-netipaddress | ft ipaddress' intikken dan 'ipconfig'. Maar het starten van Powershell duurt net iets te lang waardoor de tijdswinst al teniet is gedaan.

Hoewel je natuurlijk ook zou kunnen stellen dat je misschien juist wel Powershell als standaard 'shell' moet draaien en lekker via remoting Core-installaties moet beheren.

ik snap niet precies wat jullie met vertraging bedoelen? powershell is zelfs sneller met het weergeven van adapter config...

1e keer dat je binnen je sessie een nieuw commando aanroept, dan lijkt hij een aantal seconden te laggen. Vast module laden in achtergrond ofzo.
Dit gebeurd bij elk nieuw commando dat je invoert.

Dat klopt. Als je een cmdlet uitvoert die niet behoort tot de 'standaard' PS module, wordt de betreffende module of pssnapin op de achtergrond geladen.

Dit geldt alleen als je PS v3 of nieuwer gebruikt.
In oudere PS versies moet je de module of pssnapin handmatig laden, anders krijg je een foutmelding in de trant van "onbekende cmdlet"

Bijv: Get-ADuser

Het is erg afhankelijk van de configuratie van het systeem. Op mijn eigen PC heb ik er geen last van maar als ik bij een klant Powershell start en intik 'get-neti' gevolgd door tab moet ik altijd een paar tellen wachten.

Ah! nu zie ik het inderdaad... dat is aanzienlijk!

Huh? je typt liever 21 karakters meer. Raar.

dan krijg je echter direct het IP-address te zien, bij ipconfig moet je eerst nog even zoeken waar het ip-address precies staat

Correct Jeroen. Ik had kunnen verwachten dat iemand zou reageren die alleen kijkt naar het aantal letters wat je intikt en niet beseft dat de output van ipconfig ontcijferen meer tijd kost.

Die output moet je nog steeds ontcijferen: ik krijg 12 regels output met daartussen mijn IP adres. De rest zijn onhandige IPv6 adressen enzo. Pak dan Cygwin: ipconfig | grep IPv4. De output is dan de 2 relevante IPv4 adressen. Vast mooi dat powershell, maar echt handig? Nee.

Ja precies... pipen naar grep o.i.d. is nog altijd korter.

Ik zou de Powershell wel willen gebruiken maar om één of andere reden kom ik er nooit toe... Als ik hem open heb ik ook geen idee wat ik moet doen... Ik zou eigenlijk het liefst zien dat ze gewoon een soort bash integreren... Maar ik geloof gehoord te hebben dat ze daar ook mee bezig zijn.

Dat zit er ook al in (beta): http://www.howtogeek.com/...bash-shell-on-windows-10/

Ja dat klopt powershell en andere verwante programa's zijn gemaakt wat je vroeger met msdos kon doen.
Die msdos commando's zijn allemaal geintregeert in deze opdracht prompt (powershell).
Met de intreding van windows xp windows 7,8en 8.1 zijn deze commando's flink uitgebreider alleen maar bedoelt voor systeembeheer of serverbeheer.Een gemiddelde gebruiker gebruikt het niet je hebt het niet nodig als alles fatsoenlijk draait en dan heb ik het over de huis tuin en keuken gebruiker die af en toe eens mailt, op het internet zit en af en toe eens YouTube gebruikt en wel eens een mp3 tje mee afspeelt.Vroeger had je het wel nodig anders kon je geen programma laten draaien.
Of een spelletje opstarten.Ik heb het dan over de msdos gerelateerde programma's van vroeger.

Vast mooi dat powershell, maar echt handig? Nee.

Dan denk ik dat je nog nooit echt grondig met Powershell aan de gang bent geweest. Je kunt er echt enorm veel mee. En natuurlijk zijn er vast dingen die je met Cygwin makkelijker kunt. Maar met Cygwin kun je vast geen servers tot in de kleinste puntjes configureren, rollen en features installeren, Exchange beheren, geautomatiseerde System Center-taken uitvoeren en noem het allemaal maar op. En dat allemaal is dan ook nog eens prachtig te scripten zodat het altijd consistent gebeurt.

Doe het dan ook wel even op vergelijkbare manier en volledig latka.
Get-NetIPAddress | ft ipaddress

Met Cygwin is totaal geen vergelijk. Als je Grep gebruikt dan filter je alleen de regels waar de gekozen tekst in staat. Dat kan onder een command prompt net zo goed met 'ipconfig | find "IPv4" '

Het grootste verschil is dat jouw voorbeeld volledig tekstgebaseerd is. Powershell werkt met Objecten.

Als je het zo vaak gebruikt, dan weet je ook dat er een vaste volgorde in zit en je dus ook snel de juiste waarde kan vinden.

volgens mij duurt het ook langer op get-netipadress | Ft ipaddress ook een stuk langer dan ipconfig.

Maar de overschakeling is een goede zaak omdat je nog steed ipconfig kan ingeven in PS.
je mist dus niets met het gebruik van powershell.

enkel is winkey + cmd veel sneler en gemakkelijker dan winkey + powershell en dan de juiste kiezen, zat d'r pas tijdens het controleren bij het blindelings op enter drukken in de PS ise, ja dat heeft dan weer een splash screen en extra laad tijd.

Dat is ook de reden waarom ik steeds de command line gebruik.

Als een paar seconden voor je echt een probleem zijn heb je wel bijzonder tijd sensitieve taken. Mag ik dan voorzichtig aanraden powershell met Windows zelf op te starten? Dat is namelijk wat vrijwel alle pro's doen en dan is het slechts een klik op de taskbar.

Overigens start powershell hier zeer snel op. [Windows key], [p], [o], [enter], Het typen duurt langer dan het starten. [Windows key], [c], [m], [enter] is echter een fractie van een seconde sneller. Ik ben blij dat die fractie voor mij niet veel uitmaakt.

Win+X -> I is nog sneller (als je het Powershell vinkje hebt aangezet in de settings ipv cmd).

Als een paar seconden voor je echt een probleem zijn

Hier wil ik even op inhaken. Een paar seconden is niet veel tijd. Klopt. Maar het is te lang. Veel te lang.

Waarom?

Mensen zijn dieren. En in miljoenen jaren evolutie zijn we fantastisch aangepast aan een real-time wereld. En we hebben een mechanisme ontwikkeld dat spiergeheugen / muscle memory of motor learning heet. Hierdoor kunnen we leren om complexe taken uit te voeren zonder er bewust over na te hoeven denken. Je gebruikt dit als je loopt of fietst of auto rijdt. Ik gebruik het nu om dit te typen.

Maar spiergeheugen en vertragingen van seconden gaan niet samen. Het werkt niet. Persoonlijk schat ik de maximale vertraging die nog goed met spiergeheugen samengaat op zo'n 250 milliseconde, oftewel een kwart seconde. Gaat de vertraging daar overheen dan moeten we wachten... en na het wachten bewust het proces hervatten. Als dit de hele tijd gebeurt kun je je spiergeheugen dus niet effectief inzetten.

De echte vertraging die dit allemaal oplevert is veel meer dan de optelling van die seconden wachttijd. Het leidt tot afleiding, ergernis, fouten waardoor dingen opnieuw moeten etc etc.

Met die logica kunnen we SSDs ook wel afschaffen, want als wat langer wachten geen probleem meer is dan zijn die overbodig.

De lag die ik ervaar op mijn SP3 i3 is echt niet noemenswaardig. Oftwel: het verschil scheelt niet eens een input teken. En dat lijkt mij dan ook de enige norm als je het een noemenswaardige vertraging wilt noemen.

Xardas heeft het duidelijk over servers.

Hij heeft dan ook gelijk dat je soms echt lang moet wachten tot je de powershell omgeving hebt gestart. Dat merk ik met name bij de Exchange Management Shell, de Sharepoint Management Shell en anderen.

Het laden van de snap-ins en modules duurt soms best lang, zeker wanneer er iemand achter je rug zit te hijgen, omdat de server het niet doet.

Als je powershell op je servers met mogelijk iets ouder OS niet update, dan is ie wel traag te noemen. Server2008 is ie echt langzaam kan ik 15 cmd's starten

Maar als je die netjes update, dan is ie niet, of niet veel langzamer dan cmd

Vooral oudere versies van PowerShell hadden hier last van, en dat had volgens mij te maken met het JIT compilen van assemblies in de GAC (Global Assembly Cache). Even zoeken of ik een linkje kan vinden...

Hier: https://blogs.msdn.micros...-updating-update-gac-ps1/

komt omdat het eerst .Net framework laad, MS raad dan ook af om het in login / startup scripts te gebruiken

Windows-Toets + R, cmd, enter.
Dat start wel snel en kun je je ipconfig in uitvoeren.
Hoe eenvoudig kan het zijn?

In W10 kun je PS gewoon in je settings menu als standaard zetten voor je startmenu. (Settings -> Personalization -> Taskbar -> Replace Command Prompt With PS.

Een toggle? Je bedoelt voor het Win + X menu om te switchen tussen Powershell en CMD? Die zit al tijden in de taakbalkinstellingen, nog van voor de Creators Update. Volgens mij zelfs al in Windows 8.1.

Is dat de visie? Blijkt niet uit de system requirements van Exchange: installatie op server-core kan niet https://technet.microsoft...a996719(v=exchg.160).aspx. Dus leuk dat het via de commandprompt gaat. Maar de full-desktop experience is nodig om het product te draaien. Dat gecombineerd met dat de bulk van de exchange admins incidenteel een user aanpassen denk ik dat dat nog wel even zo blijft.

Ik weet niet wat jij ervan maakt, maar hij had het over besturen van Exchange via PowerShell. Overigens is de visie meende ik, dat alle software met een api, via
PowerShell aangeroepen kan worden. Goed voorbeeld: Azure, Office 365, ...
Ik heb al enkele jaren geen full desktop experience nodig voor Exchange (office 365).
PowerShell gebruik ik veel, vooral ook om taken te automatiseren.

Besturen gaat alsnog via Powershell. Sterker nog, in de vorige versie waren er zelfs opties die je alleen via Powershell kunt gebruiken / instellen. Het aanmaken of wijzigen van een gebruiker kan ook prima via Powershell. Meer kracht, scriptbaar en altijd op dezelfde wijze dus een lagere kans op fouten. Dat is inderdaad de visie van Microsoft. Je zult de komende tijd meer en meer Powershell tegenkomen, zeker binnen de server producten.

Ik hoop echt dat ze die belachelijke eis bij de volgende exchange versie laten vallen. Waarvoor heb je die desktop eigenljk nodig? Puur voor het uitvoeren van de installatie en initiële setup. Al de rest gaat via powershell en/of de browser (die in de achtergrond weer powershell commandlets aanroept).

Moet voor de gein eens een server 2012R2 curus volgen. Bij elke module wordt er de nadruk op gelegd dat het nu ook met powershell te beheren is (DNS, AD, DHCP, alle nieuwe features).

Exchange blijft wel het leuke voorbeeld, waarbij sommige features/handelingen alleen via powershell te doen waren tot de GUI het ook ondersteunde na een SP.

Wat meer on-topic: Powershell > CMD voor zo'n beetje 99% van de acties. 1% is voor de achterlijk simpele zaken, die ook vanuit powershell gewoon kunnen. Goede zet dus!

Geen verwijt hoor, maar heb je wel eens geprobeerd om bijvoorbeeld een DFS root of namespace aan proberen te maken met powershell, dat gaat toch met de GUI wel heel wat makkelijker

Nee, DFS heb ik zelf nog niet gedaan, maar krijg je bij het einde van de rit in de GUI niet gewoon het powershellcommando te zien, en die copy paste je dan naar je 2de DFS namespaceserver? Op de 1ste DFS-N server doe je het met GUI, en alle andere is copy paste werk, en gegarandeerd hebben ze allemaal dezelfde config!

Misschien hebben ze dat verbetert in w2016, maar zit niet in w2012

Dat gaat met Powershell ook simpel met als grote voordeel dat je het een tweede keer op exact dezelfde manier kunt doen. De documentatie is het commando of het script zelf. Powershell is juist uitermate geschikt voor dit soort taken.

Exchange is een van de vele schizofrene MS paketten:
"Windows Server 2016 Install Windows Server 2016 and choose the Desktop Experience installation option. If a computer is running Windows Server 2016 Core mode and you want to install Exchange 2016 on it, you'll need to reinstall the operating system and choose the Desktop Experience installation option."

Eindelijk. Het werd tijd, nadat men in 2011 tijdens de interne training bij Microsoft aangaf dat Server 2012 zwaar zou gaan inzetten op PowerShell. Dit had sinds toen reeds de default shell moeten zijn.

sinds server 2012 zijn alle (server)functies under the hood powershell-driven en kan je kiezen voor een core installatie zonder GUI

Ja, als je alleen filesharing doet. Exchange 2016 werkt niet op Server Core. SQL Server 2016 werkt deels. Het is het precies weer helemaal niet.

Powershell is een tool dat zeker zijn meerwaarde heeft, voor mijn job is het onmisbaar en ik heb al vaak me geërgerd aan "waarom is dit een cmd en niet powershell".

Maar lets be honest voor de gemiddelde consument boeit dit geen hol, het enige dat dit MS gaat opleveren is een aantal calls met "waarom is die achtergrond opeens blauw ipv zwart mijnheer, is er iets met mijn computer misschien?" .

Ik vind de nieuwe koers van Microsoft zeer opmerkelijk, we gaan eerst alle rechten beperken (uac) en nu gaan we vrolijk powershell uitdelen aan niets wetende gebruikers.

Natuurlijk wat in het absurde doorgetrokken maar het is toch een 180 graden bocht.

Oh ja, ook nog makkelijk, die cmdlets, voor een iedere 65+ of een huist-tuin-en-keuken-gebruiker zeker?


"Kleinzoon, heb je de de cmdlets Get-Help Get-Command al gebruikt?"
"Nee opa, ik pipe em eerst naar een variable"

Voor de zakelijke wereld....oké.

Compleet irrelevant gezien je de normale dos commando's nog steeds kunt gebruiken. Je krijgt dus meer flexibiliteit en kracht extra ten opzichte van de oudere situatie.

Als Linux/OSX gebruiker die bekend is met de verschillende shell's... kan iemand uitleggen in je eigen ervaring in 4 zinnen, wat is er bijzonder aan Powershell en hoe powershell vergelijkbaar is met de verschillende shell's binnen een Linux omgeving?

Vergelijkbaar met Bash:
Je voert een commando uit en het resultaat zie je in de terminal, haal je door een pipe naar het volgende commando, of je redirect het resultaat naar een bestand. In tegenstelling tot Bash is de input en output niet alleen plain text, maar zijn het objecten. Dit heeft soms voordelen, maar het voelt soms ook als een beperking. Beide shells kunnen als script interface gebruikt worden. Zowel Bash als PowerShell zijn redelijk krachtig op zich, maar bovendien combineer je dit natuurlijk met Perl, Python, PHP en dergelijke.

Overigens heeft Microsoft met PowerShell heel veel dingen afgekeken van Bash, naar mijn mening om de ervaring voor Bash gebruikers wat beter te maken. Zo heb je bijvoorbeeld allerlei aliasen in PowerShell die Bash gebruikers veel gebruiken, zoals ls, man, cat en dergelijke.

Beperkingen van PowerShell
Zelf vind ik de grootste beperking van PowerShell de interface. Als je het venster wilt maximaleren dan blijft de breedte gelijk. Zaken als selecteren, kopieren, plakken of navigeren door de tekst zijn echt heel onhandig. Als ervaren Bash gebruiker gaan je een aantal negatieve punten direct opvallen:

• Bij het maximaliseren van het scherm schaalt de breedte niet mee
• Standaard Emacs keyboard shurtcuts werken niet
• Tekst selecteren werkt niet per regel, alleen per blok
• Vrijwel alle commando's zijn veel langer
• Tab completion geeft geen lijst met mogelijkheden

Bash leunt veel meer op forking van processen waar PowerShell veel meer leunt op interne commando's. De commando's die je veel gebruikt zoals cat, sed, grep, cut, tail en dergelijke zijn losse applicaties, ieder veel krachtiger en dynamischer dan de PowerShell equivalente commando's. Bovendien zijn al deze applicaties afzonderlijk te updaten of vervangen voor alternatieven. Dit is niet direct een nadeel van PowerShell op zich, maar vooral een voordeel van de volwassenheid van Bash.

Ondanks dat ik wat minder positief ben over PowerShell dan over Bash zou ik toch zeggen dat ze qua functionaliteit grotendeels hetzelfde kunnen. Bash is meer volwassen, veel meer open en transparant en een veel rijkere set aan externe open-source applicaties (GNU Coreutils). Maar PowerShell juist wat stricter en meer uniform door de build-in commando's.

[Reactie gewijzigd door nesQuick op 19 november 2016 00:21]

Je kan in de instellingen van PowerShell width scaling aanzetten:
Rechterklik op titelbalk -> Properties -> Layout -> Wrap text output on resize

Jij moet eens de Powershell Integrated Scripting Environment (ISE in je startmenu) proberen.

3 van je 5 punten werken dan denk ik al meer/helemaal zoals je hoopte dat het zou doen.

Ik gebruik zelf op windows gewoon cygwin bash. CMD is te beperkt, PowerShell zit conceptueel behoorlijk anders in elkaar, en dan heb je met een *NIX kloon op Windows zomaar de kracht van sed, awk etc.

Voor Windows clusters zijn al eerder de cluster commando's verdwenen (was voorheen een aparte exe die je in een CMD kon gebruiken, zie cluster /?). Nu zijn dat allemaal powershell applets. Qua kennis/logic/omslag niet allemaal even logisch (o.a. het doorgeven van objecten). Maar dat is ook een stuk gewenning.

Het is al heel veel jaar zo dat bepaalde hardware op Windows logger/trager aanvoelt dan op Linux. Ik heb geen ervaring met Windows core (helemaal geen UI is toch vaak te beperkt). Maar simpele dingen als compileren, shell zaken, processen starten (heeft Windows een erge hekel aan als je dat vergelijkt met Linux), etc etc gaan op Linux sneller.

Overigens was CMD de afgelopen jaren ook al iets meer 'unix' achtig geworden. Een constructie als for /f "usebackq"%i in (`dir /s/b`) do echo %i was voorheen niet mogelijk. Resultaten van een voorgaand commando makkelijk in een volgend commando doorgeven is eigenlijk altijd al een zwakte geweest in Windows.

Wat ik me dan wel afvraag: blijven batch files (waarvan er miljoenen zullen zijn, inclusief login scripts) gesupport? Als de CMD default powershell wordt, dan zal er e.e.a. omvallen. De CMD interpreter is anders dan de powershell interpreter...

[Reactie gewijzigd door kdekker op 19 november 2016 11:05]

Is misschien wel niet vergelijkbaar juist. Powershell is object-gebaseerd; linux shells zijn tekst-gebaseerd.

Als ik in Powershell een dir opvraag (gci) dan krijg ik een array terug met daarin voor elk item een object. Zo'n object kent eigenschappen zoals naam, grootte, date changed, attributes et cetera.

Voer je een zelfde actie uit in de meeste Linux shells dan krijg je een lap tekst terug.

Een soort Python interpreter dus? Die zit trouwens ook bij OS X standaard meegeleverd

Powershell tracht de grote kracht van de pipeline te gebruiken. Dat is wat Jeffrey Snover oorspronkelijk inspireerde, echter Unix tools for Windows werkten niet omdat Unix tekst georiënteerd is en Windows api/object based. Doordat er objecten worden doorgegeven blijf je de kracht van objecten houden waardoor je hun properties en methods kunt blijven gebruiken. Enorm krachtig

Waar bijv. Bash alles met string van het ene command naar het andere piped zijn dit in Powershell objecten. Vergeleken met Command Prompt is Powershell echt een verademing. Het hele .Net framework is tot je beschikking in Powershell en als je het echt zou willen zou je er complete programma's in kunnen schrijven.

PowerShell ondersteunt verschillende shell's tegelijkertijd. Je kan dus al je dos commando's gebruiken maar ook gewoon VBScript command's of .net. Het bied je de mogelijkheid om scripting te combineren met programmeren.

Het is extreem krachtig. Ik gebruik het voor alle interfacing waarbij ik een FTP tool als Putty kan combineren met com objecten waardoor ik ook de binnenkomende XML bestanden kan valideren of zelfs corrigeren in de interface scripts.

Hierdoor kan ik supersnel inspringen op veranderingen waardoor ik minder afhankelijk ben van de release kalenders van de verschillende systemen waarmee ik werk.

[Reactie gewijzigd door wiseger op 18 november 2016 20:23]

Ik heb het zelf nog niet geprobeerd, maar Powershell is nu ook beschikbaar voor OSX en Linux.

Poeh, ik schrok al.
Zonder cmd.exe zou mijn leven een stuk somberder worden.
Gelukkig verdwijnt deze voorlopig niet :)volledig.

Voor je eigen plezier. Leer powershell. Btw. Alle native dos commando's werken in Powershell

'dir /s' is in powershell toch wel heel wat anders dan in de command prompt. Dat, en nog een hoop andere wijzigingen, leer je niet zo eventjes af.

Natuurlijk werk ik gewoon met Powershell.
Soms omdat het handig is, regelmatig omdat het noodzakelijk is.
Veel dingen gaan echter nog steeds efficiënter (met wellicht minder mooie output) vanaf de .cmd dan vanuit PS.

Powershell gaat gelukkig verder dan CMD. Alles wat je met CMD kan kun je met PowerShell ook en dan nog veel en veel meer. Als groot liefhebber van CMD was ik aangenaam verrast met PS al was t maar omdat veel unix dingen ook werken.
Ik vind dit een goede zet van MS, meer PowerShell is meer beter \o/

Bijna alles: dir /? doet'ut niet (find /? dan weer wel).

dir is geen dir meer, maar een alias voor Get-ChildItem. Hierdoor is het ineens een powershell cmdlet geworden, waarmee je heel krachtig te werk kunt gaan.

Powershell is namelijk objectgeoriënteerd. Wanneer je dir gebruikt in een pipe naar een ander commando (dat doe je met behulp van het | symbool), dan stuur je de uitvoer van dir naar dat andere commando. Aangezien powershell objectgeoriënteerd is, wordt nu niet de schermuitvoer doorgestuurd, maar zijn al jouw folders en bestanden in jouw dir uitvoer ineens objecten geworden. Objecten worden in Powershell opgeslagen in een variabele met de naam $_. Variabelen beginnen in Powershell altijd met een $ teken en de _ variabele is dus "current object".

Kleine demo:

type in powershell de volgende commando's:

c:
cd \windows
dir
dir write.exe | format-list
(je ziet dat write.exe als object veel meer properties heeft dan wanneer je simpelweg een "dir" zou geven. Blijkbaar is write.exe als object zijnde doorgestuurd naar het commando format-list, waardoor je ALLE eigenschappen van write.exe kunt bekijken!!! Nu zie je dat write een hardlink is (linktype) naar een andere plek waar write.exe staat.)
dir | Where-Object {$_.LinkType -eq "HardLink"}
(nu zie je dat er meer programma's zijn die van het type "hardlink" zijn.

Powershell FTW

Ik weet wat powershell is, maar het is geen dropin voor CMD.exe, zeker als ze een deel van de bekende commando's anders verwerken. En dat het objectgeorienteerd is ipv. karakter gebaseerd is leuk, maar niet relevant. Waar ik me vooral mateloos aan irriteer (maar wellicht is dat mijn autisme) is de UppPeR LOWeR case diaree die niet consequent is: format-list en Get-ChildItem? Get real.

Dank voor de rant. Ik zal proberen mijn kritiek op Powershell beter te onderbouwen. Vooropgesteld: ik gebruik powershell zeer incidenteel.
Een deel van mijn werkzaamheden bestaan uit het onderhouden/deployen van applicaties. Veel op Unix machines, maar steeds meer op Windows platformen. Wat ik zie gebeuren om mij heen is dat met Powershell iedereen aan het scripten slaat. En, in aloude IT traditie, vergeten we de lessons learned want NIMBY. Zo heb ik scripts gekregen zonder commentaar met de opmerking: het script is het commentaar. Leuk.
Ook aardig: de scripts staan in mijn home-dir, kijk er maar even naar.
Powershell had een mogelijkheid kunnen wezen om beheren van omgevingen uit het stenen tijdperk te halen, dat is niet gebeurt. In plaats daarvan krijgen we snippets en scripts waarvan de kwaliteit afhankelijk is van de persoon achter knoppen en de techniek helpt hier nauwelijks bij. Dat alles wordt overgoten met een sausje object georiënteerd en meer mystificatie zonder het echte probleem op te lossen. Vragen die ik zou hebben zijn:
1) Welke scripts/settings zijn er sinds de installatie van het product gedraaid en door wie (en met welke reden)
2) Terugdraaien van een configuratie wijziging zonder een rollback script te moeten maken
3) Configuration matching ala puppet: dit is de config die ik wil hebben, waar wijkt mijn inrichting af van de gegeven configuratie

In plaats gereedschappen om dit te doen geeft powershell je een doos hagel en mag je gaan schieten. Geen haar beter dan een Bash script dus maar kost wel weer ellendig veel tijd. Maar ach, wat zeur ik: ik wordt per uur betaal.

1) Je kunt met Start-Transcript alle commando's die in Powershell gebruikt zijn, inclusief de schermuitvoer, bewaren in een logbestand. Wanneer je ervoor zorgt dat een powershell scherm standaard start met Start-Transcript en wanneer je zorgt dat de naam van de logfiles de datum bevat en eventueel de naam van de ingelogde gebruiker, dan kom je wat punt 1 betreft, al een aardig eind.
2) Zoek even in Google naar: DSC (Desired State Configuration). Hiermee kun je een consistente configuratie enforcen en eenvoudig wijzigingen terugdraaien.
3) Hier heb ik nog even geen antwoord op.

Je kan natuurlijk Powershell tweaken zodat het er haast identiek uitziet als je het zou missen dan heb je dezelfde GUI maar een heel arsenaal extra mogelijkheden in hetzelfde boxje .

Goed dat ze dit doorvoeren. Handig voor powerusers, en de doorsnee gebruiker zal het niet merken. CMD zal er wel nog een tijdje in moeten blijven omdat sommige software het ook wel eens gebruikt (jep, ook software die vlotjes op Windows 10 draait).

Je kan altijd nog een Portable Command gebruiken

• http://portableapps.com/a...s/command_prompt_portable
• http://portableapps.com/apps/utilities/console_portable

als alle native dos commando's werken onder powershell waarom zit de oude command prompt er dan nog überhaupt in?

In ieder geval backwards compatibility. Je zult maar software of scripts hebben die gewoon cmd.exe direct aanroepen met een paar parameters erbij. Daar werkt dan helemaal niets meer van, en krijgt MS een slechte naam.

Edit: Ow, en even een linkje gevonden, voor ik het hier ging verkondigen zonder dat ik het precies wist:
https://blogs.technet.mic...heir-weirdest-parameters/
Niet alle CMD commando's werken. "SC QUERY LANMANSERVER" werkt niet, maar "SC.exe QUERY LANMANSERVER" werkt wel. Je kunt geen aanname doen dan iedereen dat laatste had.

[Reactie gewijzigd door Wafeltje op 18 november 2016 20:09]

tja, of ze fixen powershell gewoon dat die dingen wel kunnen... en zorg dan dat wanneer cmd.exe wordt aangeroepen gewoon powershell start..

tja, of ze fixen powershell gewoon dat die dingen wel kunnen...

Dat gaat niet. Je zult altijd wel wat breken. Een fix die voorkeur geeft aan sc.exe zal PowerShell scripts breken die sc als alias voor Set-Content gebruiken. Zie ook: https://github.com/PowerShell/PowerShell/pull/1901

En wat dacht je van escapen van quotes en weer doorsturen naar een andere exe. Wat een drama kan dat zijn.

Maar was die laatste dan niet sowieso best practice?

Compatibiliteit ? Cmd commando's werken niet 100% hetzelfde binnen powershell. Commando's als dir zijn bijvoorbeeld een alias van get-childitem en de output is een object, geen tekst.

Ik snap wat ze willen doen, maar laat PS dan iig binnen 4 seconden opstarten.
Bij cmd hoefde ik nooit te wachten.

Zal wel aan je installatie liggen gezien die hier even snel opstart als cmd.

Ik heb hetzelfde, eigenlijk op alle servers van klanten. Het is niet zozeer dat het langzaam start, maar voordat je een commando kan uitvoeren ben je inderdaad gauw 4 seconden verder.

Bij starten van PowerShell leest het programma Profile.ps1 in, hoe voller de profile, hoe langer het duurt.
De Profile.ps1 zit zowel in je profiel als Windows directory.

Als in je profiel bepaalde modules geladen worden zal het nog langer duren.

Thanks! Ga ik eens in de gaten houden

Type $profile en je ziet welk profile gebruikt wordt.
$profile | notepad $profile
of
$profile | PowerShell_ISE.exe $profile
.

[Reactie gewijzigd door 614 op 19 november 2016 13:19]

Het venster is er al snel, maar de prompt zelf duurt nogal lang.
Meestal ben ik dan al lang en breed (zichtbaar) aan het typen, en plots komt die prompt ervoor te staan.
Nogal irritant.

En ik zit niet op een SSD.

[Reactie gewijzigd door Nbgangsta op 18 november 2016 20:02]

Het kan wezen dat in je PowerShell profiel wat dingen automatisch opstarten. Check WindowsPowerShell in je documents folder even of daar misschien wat in staat.

Alles voor Windows 8(.1?) en Server 2012 (R2?) heeft Powershell nog niet gecached draaien. Vanaf deze versies wordt Powershell al geladen bij het opstarten en is het dus snel beschikbaar.

Ik gebruik de laatste tijd ook de powershell vaker dan de command prompt. Komt waarschijnlijke door al die kleurtjes! Ziet er overigens een stuk netter naar mijn mening uit.

Kleur van de CMD kan je aanpassen via de... CMD

C:\>color 1
C:\>color 2
C:\>color 3

...enz

Of even op het icoontje klikken, linksboven in de title-bar > properties > colors.

Ik denk dat ie vooral de toegepaste kleuren bedoelt. Om zaken te accentueren. Syntax highlighting, zeg maar. Ben ik ook erg blij mee!

Color 1F voor de powershell kleuren!

Tab completion in PS is zo verrekte handig. Soms loop ik al te tabben in een cmd box (waarom doet 'ie het nou niet?) En de visuele editor (ISE) is ook makkelijk, voor als je scripts wilt maken.

Tab completion bestaat ook in cmd, maar niet voor alles. Bestandsnamen en paden maakt ie keurig af (meerdere keren op tab voor volgende file/dir).

Commandline??? Dat is zo jaren 80, ze kunnen beter goede overzichtelijke userinterfaces maken waarin alle opties beschikbaar zijn. Leuk hoor dat je stoer kunt doen door te laten zien hoe goed je alle powershell commands uit je hoofd kent, maar ik heb liever een goed uitgedachte UI voor monitoring en eenmalige configuratietaken. Commandline gebruik ik liever voor bulk zaken, zoals 100x dezelfde setting bij alle users aanpassen oid. Maar zelfs dat zou je met een goed UI ontwerp makkelijker kunnen moeten doen. MS is gewoon lui geworden, ff snel een commandline tool maken is veel makkelijker dan goed nadenken over de UI.

[Reactie gewijzigd door Stephanoid op 19 november 2016 11:47]

Ik gok dat 99% van de professionele IT'ers het niet met je eens is. Het heeft dan ook niets met luiheid te maken, maar met marktwerking. UI's zijn slecht te scripten, een CLI heeft dat probleem niet.

[Reactie gewijzigd door .oisyn op 19 november 2016 14:38]

Zo slecht vind ik het anders niet wat Microsoft tegenwoordig met Windows 10 presteert. Apple mag nog uitkijken omdat ze meer professionele gebruikers behoorlijk teleurstellen met de geringe opslagen werkgeheugenmogelijkheden van de onlangs gepresenteerde MacBook Pro lijn.

Niet iedereen kan zomaar alles doen met een UI, in een script ben je veel flexibeler in hoe je zaken regelt, hoe je export er uit ziet etc.
Bovendien zijn aanpassingen in een script zelf te realiseren, in een door de fabrikant gemaakte UI niet.
Ik script al jaren heel veel en dat stellen mijn collega's en klanten op prijs.

En mocht je, om wat voor reden dan ook, liever de commandprompt willen hebben dan powershell, dan type je even cmd en druk je op enter.

Er komen nog veel meer mooie improvements aan! Windows exe files runnen in Bash On Windows en 24bit kleur support in de windows console onder andere.

https://channel9.msdn.com/Events/Connect/2016/191

Persoonlijk kunnen ze 2 modes beter scheiden.

MS-DOS prompt voor legacy modes alla win98 stijl en misschien een emulator voor 8 en 16 bit software er omheen bouwen.

En Powerschell voor de poweruser taken. Het liefst ook een beetje sneller.

Zo blijven legacy applicaties altijd werken en zijn powerusers eindelijk van die oude draak af.