Microsoft gaat PowerShell 2.0 verwijderen uit Windows

Microsoft stopt met PowerShell 2.0. De tool, die al jaren niet meer wordt ondersteund, verdwijnt uit Windows, hoewel dat in sommige applicaties nog wordt gebruikt. Het is nog niet duidelijk wanneer dat precies gebeurt.

Microsoft schrijft dat PowerShell 2.0 verdwijnt uit een Canary-build van Windows 11, specifiek Build 27891. Ergens in de komende maanden moet de tool ook definitief uit Windows 11 worden verwijderd, maar Microsoft zegt daar op een later punt nog meer informatie over te delen.

PowerShell 2.0 is een oude versie van de cli-tool. Het zat al in Windows 7, maar Microsoft liet bij Windows 10-versie 1709 weten dat PowerShell 2.0 werd uitgefaseerd. De tool kreeg toen de deprecated-status en zou niet meer worden bijgewerkt. In plaats daarvan kwam PowerShell 5, wat de huidige versie is, en inmiddels is er ook PowerShell 7 met nog meer features.

Hoewel Microsoft al jaren waarschuwt dat versie 2.0 deprecated is en dat gebruikers het beste kunnen upgraden, zat PowerShell 2.0 nog altijd wel in Windows 10. Er was nog veel software, waaronder Microsofts eigen SQL Server, dat in het verleden nog gebruikmaakte van PowerShell 2.0, maar daarvan zijn de meeste nieuwe builds bijgewerkt waardoor de software aan relevantie heeft verloren.

Reacties (116)

[michelr]

Niet geheel onbelangrijk - PS2 hangt aan .NET CLR2 (2-3.5). Dat is al jaren een dood paard.
Verder is PS2 in Windows 11 optioneel; dat het eruit geyeet wordt is prima. Wie nog spullen heeft die ervan afhankelijk zijn hebben al een tijdje gehad om de boel bij te werken.

[bantoo]

Aha dat verklaart het nodige. Geeft ook aan waarom PS5 nog 10+ jaren te leven heeft waarschijnlijk aangezien .NET framework nog lang niet EOL is.

[michelr]

Dat er zo lang zoveel ouwe meuk gesupport moet blijven is idd een belemmering. PS5 is - nog steeds - de defacto PS bij menig klant. Daar zit wel een kleine verschuiving in, met name als er Azure Runbooks ingezet worden.

[Mellow Jack]

Dat komt vooral door het verschil tussen .net (Windows only) en .net code (multi platform). Veel zaken hebben ze niet gereed gemaakt voor .net core. Zoals bijv. de active directory modules. Ben niet helemaal op de hoogte maar hoorde dat ze voor het eerst sinds bijna 10 jaar een AD schema update hebben uitgebracht dus misschien dat ze hier ooit nog een .net core voor gaan inzetten maar ik betwijfel het.

Zolang dat het geval is zal Powershell 5.x blijven leven en misschien zelfs de defacto standaard zijn

[Noxious]

Een goed voorbeeld daarvan is ook WAC (Windows Admin Center). Beheertooling voor je servers die op zich redelijk werkt (als je een beetje door de bugs heen kan kijken); echter er is nu (eindelijk) een preview beschikbaar die op basis van de nieuwe dotnet is gemaakt - mist enkel wel support voor heel veel modules; dus veel mensen kunnen daar (nog) niet heen switchen.

Veel van dit soort dingen bij MS de laatste 10 jaar ofzo. Hetzelfde als de nieuwe configuratieschermen die tal van opties missen. Alles is onaf of maar half compleet.

[Audiodude]

Waarschijnlijk ook omdat ze zelf AzureAD en Entra willen promoten.

Gebruik zelf heel veel Powershell. Voor mij beter als Python / Azure cli met zijn dependency hell en eindeloze conda omgevingen. Zeker als alles potdicht staat op de machine learning omgevingen.

Heb veel eigen modules, soms aangevuld met C# functionaliteit, die je moeiteloos kan laten communiceren met diverse APIs van leveranciers, SQL servers en eigenlijk bijna alles in onze omgeving. (Bank omgeving)

Als je Cloud Engineer en/of DevOps werk met IAC op Azure doet, is het zeer prettig werken.

[Yalopa]

Grappig, ik vind azure cli in combinatie met bash net prettiger werken dan powershel.

Elk z’n ding zeg maar.

[Reactie gewijzigd door Yalopa op 5 juli 2025 19:06]

[dasiro]

Dat er zo lang zoveel ouwe meuk gesupport moet blijven is idd een belemmering. PS5 is - nog steeds - de defacto PS bij menig klant.

Veel software blijft jaren lang nog in gebruik nadat de fabrikant er zelf al een einde aan heeft gemaakt, al dan niet door er nieuwere versies van uit te brengen waar opnieuw in moet worden geïnvesteerd, terwijl de onderliggende omgeving er nog wel ondersteuning voor biedt en Microsoft draagt legacy hoog in het vaandel (misschien niet meer zoals vroeger), want dat levert een brede userbase op die er vertrouwen in hebben.

[GertMenkel]

Het .NET-framework lijkt wel langzaam aandacht te verliezen nu de focus gedeeltelijk lijkt te liggen op .NET Core. Voor Core moet je weer op PS6+ zitten, en aangezien Core en Framework niet helemaal compatible met elkaar zijn, kan dat een uitdaging vormen.

PS5 is uitgekomen met Windows 10 en 5.1 kwam met Windows 11. De support lifecycle van Microsoft geeft aan dat PowerShell support eindigt wanneer support voor het OS waar het bij mee kwam eindigt. Dat betekent dat PS5 waarschijnlijk support kwijtraakt zodra Windows 11 dat doet. Vanaf Windows 11 doet Microsoft daar heel vaag over (lijkt me hel om daar als bedrijf omheen te plannen), maar momenteel hebben we weinig garantie voorbij 2029, tenzij je een industriële versie van Windows draait die je niet zomaar in de winkel kan kopen. Ik zou er niet van uit gaan dat PS5 nog tien jaar heeft, in elk geval niet in een versie die je zomaar kan gebruiken; de garantie is momenteel nog zo'n vier jaar.

[Glashelder]

Kleinigheidje maar sinds versie 5 is het gewoon .NET en geen dotnet core meer.

[GertMenkel]

Je mag Microsoft daarvoor bedanken, want .NET Framework en .NET Core zijn allebei .NET (geweest). Als ik schrijf "is van .NET Framework naar .NET gegaan" staat dat alsof ik een klap van de molen heb gekregen. Ik zie de naamgeving die MS aan hun producten geeft maar als bewijs dat ze al jaren stiekem generatieve AI hebben, want geen mens kan daar een strategie aan koppelen.

offtopic:
Overigens, als we pedantisch gaan doen, PS6+ zoals ik benoemde is nog steeds op Core gebaseerd, namelijk op .NET Core 2.0, met .NET Core 7.0 op Core 3.0. Pas sinds .NET 7.1 is PowerShell niet meer op .NET Core gebaseerd, ondanks dat het een nieuwere versie van praktisch dezelfde codebase is.

Microsoft heeft overigens de memo ook nog niet meegekregen in hun documentatie van vorig jaar:

From PowerShell 5.1, there are multiple editions of PowerShell that each run on a different .NET runtime. As of PowerShell 6.0 there are two editions of PowerShell:

Desktop, [...]

Core, which runs on .NET Core. [...]

[Glashelder]

Je zal mij niet horen zeggen dat het niet verwarrend is

[84hannes]

Als ik schrijf "is van .NET Framework naar .NET gegaan" staat dat alsof ik een klap van de molen heb gekregen.

Herkenbaar, ik kwam laatst een oud document tegen waarin ik het "the framework formerly known as .net core" noemde ik verwarring te voorkomen.

[VHware]

PS5 is uitgekomen met Windows 10 en 5.1 kwam met Windows 11.

Uhm dat klopt niet

PowerShell 5.1 was officially released in August 2016 with the Windows 10 Anniversary Update and Windows Server 2016.

Powershell 5.1 is al een stuk ouder dan Windows 11.

[GertMenkel]

Je hebt gelijk. Wat ik bedoelde te zeggen was "PS5 is de nieuwste versie van PowerShell die uitgekomen was met een besturingssysteem, Windows 11". De meeste computers die 5.0 hadden, hadden een jaar later waarschijnlijk al 5.1.

[Settler11]

Sorry, maar PS2 lees ik niet anders dan PlayStation 2.

[Tim_bots]

Bij deze quote wil ik toch een opmerking plaatsen

Wie nog spullen heeft die ervan afhankelijk zijn hebben al een tijdje gehad om de boel bij te werken

In de industriële automatisering koop je een machine voor niet 5 jaar maar 10 á 20 jaar. Indien de machine met een beetje onderhoud 30 jaar kan doordraaien, graag.

Echter, op het moment dat er een probleem/wijziging is met de machine, zul je toch echt 20 jaar joude software moeten draaien om de PLC's en andere componenten bij te kunnen werken.

[michelr]

Industrie loopt idd vaak enorm uit de pas, maar de levensduur van apparaten overstijgt al gauw de levensduur van een softwareproduct (helemaal nu). Waar je vroeger niet opkeek als er Windows embedded gebruikt werd voor een terminal, doet een XP nu menig wenkbrauw fronsen. Datzelfde speelt ook al op die videoconferencing spullen; of niet upgradebaar (hallo Cisco), of versnelt afschrijven, en niet bijwerken is al snel een liability. Iemand nog floppies voor de 747 of het ISS? "Legacy kennis" verdwijnt snel, zeker omdat nieuw personeel vaak liever met hippe dingen bezig is.

[Martinspire]

Mja dit soort oude baggage is waarom Windows toch nog veel problemen heeft met compatibiliteit de laatste jaren. Als dit weg is, kan er aardig wat meuk uitgesloopt worden.

[svenM]

Dit soort oude bagage is net waarom je Windows 1 kan installeren en upgraden naar Windows 11, omdat Microsoft de dingen meestal backwards compatible houdt.

[MMaster23]

Dit artikel schrijft slecht over de verschillen tussen Windows Powershell en Powershell. Windows Powershell is waar dit artikel op slaat en waar meerdere versies zoals 2.x en 5.x van zijn. Powershell (nu op versie 7.5.2) is cross platform en draait op Windows, Linux en Mac (zij het wel met minder Windows specifieke commando's) en is gebaseerd op een subset van .NET (ipv het hele .NET Framework op Windows).

What is Windows PowerShell? - PowerShell | Microsoft Learn

Differences between Windows PowerShell 5.1 and PowerShell 7.x - PowerShell | Microsoft Learn

[Reactie gewijzigd door MMaster23 op 5 juli 2025 13:08]

[Probook8979]

Bedankt voor de link

[ro8in]

Powershell was voor mij het geen waardoor ik eigenlijk helemaal van Windows ben afgegaan naast een enkele Game PC. Toen het ooit uitkwam was ik het zeker eens met dat Windows heel hard een echte terminal nodig had met meer mogelijkheden dan de dos prompt. Echter waar ze mee kwamen was een shell waar ik echt alles moest leren bijna vanaf het niveau alsof ik voor het eerst een computer aanraak. Daarbij helpt het niet mee dat commando's opmakende dan uit de paar keer dat ik het geprobeerd heb gewoon totaal geen logische benamingen hebben. Het is een overcomplex ding waar ik afgezien van de standaard dos prompt commando's ik echt geen idee heb van wat ik moet invoeren om iets gedaan te krijgen.

Waarom niet gewoon een Unix like shell zoals elk ander OS wat zich al jaren bewezen heeft zo een beetje tot perfectie te voorzien in alles wat je van een Terminal zou willen?

Iets was zelfs Microsoft onderkend doordat ze later alsnog WSL hebben toegevoegd in Windows, maar dan weer op een manier dat ondanks dat zeker met WSL2 het best goed werkt je toch tegen rare wsl specifieke quirks blijft aanlopen.

MacOS heeft gewoon een Unix shell waarbij ik bijna wel voor 99,9 procent kan zeggen dat wat ik op Linux doe ook altijd op MacOS kan. Met WSL is dat echt wel een ander verhaal en toch wel situaties gehad welke dan gewoon simpelweg niet werkend waren te krijgen op WSL.

Tja eigenlijk is Windows nog het enige relevante OS dat niet op een Unix like kernel draait en down de road zit dit hun gewoon tegen. Het werkt allemaal prima zolang je in het Microsoft eco systeem verblijft. Maar zoveel innovatie en nieuwe dingen ontstaan tegenwoordig via Unix like systemen en wil je daarmee werken is het tegenwoordig altijd wachten op een soort halfgebakken Windows versie of een alternatief van Microsoft zelf.

Vroeger was Windows het OS waarmee je wist dat je op zeker gewoon wel alles kon doen. Tegenwoordig afgezien van consumenten software gebruiken is dat eigenlijk andersom. Je moet maar hopen dat er ook een Windows versie komt of dat je het met veel gedoe in WSL aan de praat krijgt.

Om een simpel voorbeeldje te noemen Docker images zijn bijna altijd Unix gerelateerd, Docker op Windows draait de containers onder WSL. Je denkt nou dan instaleer ik toch gewoon Docker in WSL en hoef ik die hele halfgaar Docker desktop niet in Windows te instaleren. Op elk ander OS pak je de package manager commandline ff erbij apt install Docker whatever en heb je gewoon je Docker cli en kan je aan de slag. Niet op Windows, heb jij in WSL apt install Docker gedaan, dan zit je al in de problemen want alles wat je erna probeer gaat niet meer werken. Dus je kan eerst beginnen met docker echt volledig uit wsl te verwijderen, daarna moet je docker desktop voor windows instaleren en daarmee krijg je ook de docker cli beschikbaar in WSL. Als het eenmaal werkt kan je maar beter daarna Docker nooit meer updaten want al vaker is gebeurd dat Docker gewoon stopt met werken na een update en kan je weer opnieuw beginnen.

Het is een van de vele voorbeelden waar ik gewoon telkens met Windows tegenaan loop.

Waarom Powershell als je er vervolgens niks mee kan behalve Microsoft dingen? Wat heb ik aan een hele uitgebreide Terminal als ik vervolgens nog steeds niet kan werken met alle coole innovatieve projecten over de hele wereld? WSL was een pleister, WSL2 is een verband, wanneer gewoon UnixPowerShell 8 ofzo? Powershell zoals het is is gewoon een beheer commandline tool voor ITers die met Microsoft spul werken. Maar verder heb je er niks aan.

Sorry verder onrelevant tot het nieuws dat Microsoft stopt met Powershell 2, beter stoppen ze er helemaal mee en integreren ze gewoon een native Unix compatible shell zodat Windows misschien weer een beetje kan functioneren als het OS waar je gewoon alles mee kan.

[bantoo]

PowerShell is een fundamenteel krachtiger ontwerp dan de Unix Shell. Het heeft nogal wat voordelen om daadwerkelijk objecten te verplaatsen en de optie om met .NET dingen uit te breiden. PowerShell is echter op de professionele gebruikers gericht en inderdaad niet echt sexy voor het schrijven van korte commandos.

[Sebazzz]

Inderdaad, ik gebruik het uitgebreid in mijn sysops werkzaamheden en je kan ook self-contained modules (Powershell Modules) gemakkelijk uitwisselen via Powershell Gallery en installeren via Install-Module. Denk aan modules om AWS, Azure, of delen van Windows te beheren. Zodra je object georienteerd aan de slag gaat kan je hele effectieve scripts of zelfs bijna programma's schrijven.

[Guru Evi]

Het probleem is zoals hierboven geschreven dat letterlijk niets gestandaardiseerd is. Met Unix weet je tenminste al sinds de jaren 70 dat er tekst in en tekst uit zowat alle commando’s komt en dat bijvoorbeeld opties doorgegeven kunnen worden. Daarnaast zij de de meeste commando’s relatief beknopt zowel het commando zelf alsook de opties.

Met PowerShell is dit allemaal buitengegooid, zelfs Microsoft’s eigen tools volgt geen standaard. Is het Create- of Add- of New-, in principe is dit op te lossen door CRUD op objecten te standaardiseeren zodat je als programmeur de functies implementeert maar de taal altijd de <actie>-<object> doorgeeft. In vele gevallen zijn opties context-afhankelijk en hopen is gewoon niet geïmplementeerd en moet je dus OLE of WMI commando’s via PowerShell uitvoeren. Qua input en output, de SQL-interface is fijn maar werkt niet altijd, in principe zou je ook altijd aanspraak moeten kunnen maken op de JSON voor gebruik in vb Python, maar het object krijgt dan afhankelijk van implementatie vaak ook de properties van letterlijk alle parent class objects (incl. de hele WMI database) of afhankelijk van het object helemaal geen referentie naar het object type zodat je dus JSON die je uit PowerShell haalt niet direct kan doorstreamen naar een ander PowerShell.

Probeer maar eens met USB en Hardware te werken met de spaghetti dat PowerShell is.

[Reactie gewijzigd door Guru Evi op 5 juli 2025 17:40]

[Scriptkid]

Ik ben zelf al 7 jaar power shell master trainer bij MS. Moet zeggen herken je issues niet echt.

Het ligt natuurlijk wel aan je kennis nivo want als je declarative schrijft en met runs paces kunt werken is het rete snel, simple n robust.

Heb scripts geschreven van 50k lines code die stabiel en paralel draaien en binnen 24 uur zelfde deden als andere scripts in 30 dagen.

[Guru Evi]

Een programma van 50k lijnen is niet in 24u te schrijven noch zal het overzichtelijk zijn. Dat is 2k lijnen per uur, lol.

En dan zitten we al ver buiten het idee van een script, een script is iets dat ik in 2-3 lijnen kan schrijven en een taak uitvoeren. Als ik al moet beginnen denken aan classes voor een systeem te automatiseren zie je het probleem.

Zoiets als “geef de UID (of GUID) van een gebruiker” en geef aan als hij in een groep behoort

Op Linux: id user | grep groep werkt nagenoeg onafhankelijk van je login systeem (SSSD, Winbind, AD, LDAP).

Op PowerShell - is het een AD gebruiker of een lokale gebruiker of misschien een gebruiker binnen een applicatie zoals SQL Server of een cloud ID.

Get-ADUser (Get-ADGroupMember -Identity "groep" -Recursive | Where-Object { $_.SamAccountName -eq "user" .DistinguishedName -Properties *

Let wel dat dit niet noodzakelijk werkt als je gebruiker in een ander systeem dan “oude AD” staat. Zoals gezegd, gebruik je LDAP of Entra, herschrijf maar.

[Reactie gewijzigd door Guru Evi op 6 juli 2025 01:21]

[Scriptkid]

24 uuur runtime. VS 30 dagen runtime.

Via nativeldap kun je ook gewoon groep ember expension aan Ad vragen.

De modules zijn er voor simplicity voor gebruikers met minder kennis, alleen is er geen centraal module architectuur.

Maar je kunt gewoon zelf je eigen snellere en betere module en classes schrijven. Ik gebruik zelf altijd native ldap omdat het veel sneller is dan de module overhead.


Ik ben zelf niet thuis in Linux maar hoe weet Linux in je sample welke data store hij de group exspantion moet doen en hoe auth hij dan tegen die store aan? Dan moet wel een grote complexe class zijn die daar achter zit.

[Reactie gewijzigd door Scriptkid op 6 juli 2025 09:12]

[Guru Evi]

Ik heb Python scripts die weken tot maanden draaien, dat is nu echt geen grote lift (misschien wel voor Windows mensen lol).

Ik ben vooral niet van plan om mijn eigen modules te schrijven voor een scripting taal, daarnaast moeten die modules ook meereizen als ik een van de duizenden computers inlog die we beheren. Daarom wil je precies dat een scripting taal eenvoudig is.

id werkt onafhankelijk van de achterliggende authenticatie modules, alles is in een systeem te vinden (PAM). Dat is nu precies de kracht van Unix en dat Windows omdat het nog steeds een (single user) D(esktop)OS is nooit achterhaald heeft.

Let wel dat dit niet enkel op Linux werkt, nagenoeg alle Unix hebben dezelfde functies. Misschien anders geïmplementeerd maar id en grep of awk zijn simpele utilities die werken op Android en Mac en zOS en AIX, en indien WSL geïnstalleerd, zelfs op Windows.

Ik ken mijn PowerShell wel, ik bouw Ansible modules voor Windows in PowerShell en daarmee weet ik dus hoe belabberd de taal is tov een Bash of Python. Als je in je scripting taal een andere taal er moet bijhalen (C#) om uit te breiden op wat relatief simpele code is, is het voor mij “niet compleet”.

Kijk naar dit voorbeeld: zet een computer open voor een remote shell, op Linux is dit 1 lijntje (systemctl enable sshd) en een config file (/etc/ssh/sshd_config)

https://raw.githubusercontent.com/ansible/ansible-documentation/devel/examples/scripts/ConfigureRemotingForAnsible.ps1

[Scriptkid]

Wel 1:1 vergelijken

In windows PS is het ook maar 1 lijn: (Uit jouw script)
Enable-PSRemoting -SkipNetworkProfileCheck -Force -ErrorAction Stop


de rest is allemaal controle code voor windows overhead en heeft niks met remoting winRM te maken. Als je al die checks in linux toe voegd heb je zelfde overhead.

En over je pyton die maanden draait kun je dat ook optimaliseren dat het in controleerbare parralele sessions draait als een factory zodat het in 24H klaar is , juist dat is de kracht van PS wat ik probeer duidelijk te maken. En hoe zit het met UI in pyton ? of een webserver hosten in native Pyton met lijn of 5 code.

Ja PS is niet heilig maar juist omdat het zo veel meer is dan een cmd line , het is een extensible scripting taal kun je er zo veel meer mee in een 1:many OS.

Voorbeeld met je modules mee roamen iS JUIST een kracht van PS dat je dat kunt laten doen (Blijkbaar ben je hier niet bekend mee.), Je modules kunnen als je het goed doet Juist van je beheer pc waar hij staat ingeladen worden op je werkstation als 1 single source of truth zonder dat je het instaleerd of download naar een 2de of 100ste pc

[Reactie gewijzigd door Scriptkid op 6 juli 2025 21:51]

[Guru Evi]

Bedoel je python -m http.server

En Enable-PSRemoting is niet genoeg, daarmee dat al die controle code erbij moet zitten omdat het afhankelijk is van een reeks variabelen in 3 verschillende subsystemen.

En probeer maar eens PowerShell op Linux te gebruiken, het is een taal, maar behalve de basis kan je er niets mee doen, juist omdat PowerShell gebaseerd is op COM en WMI en DOS en al die dingen niet in een Linux systeem zitten. Probeer maar eens AD module op Linux of de Firewall module op Mac te gebruiken. Net zoals .NET op Windows een volledig andere taal is dan C#/Mono op Linux.

[Scriptkid]

Maar nu draai je het om en wil je met PS niet meer Linux beheren maar met linux windows beheren dmv PS dat is nooit een goal geweest van Powershell, Het is bedoelt om de machines te managen vanuit je windows omgeving via 1 command line tool of script taal in een 1:many

En je komt telkens weer met cases die totaal anders zijn dat de root discussie,

ik ga ook niet vragen of python zelf modules en commando abstracten kan schrijven op basis van een API , iets wat PS wel kan.

De root was dat het traag was terwijl je juist beter gebruik kunt maken van de hardware als je maar snapt hoe en in paralel kunt werken met runspaces en factorys is PS,

En dat je objecten niet altijd juiste refs hadden waardoor je het niet kon doorsturen , maar met export CLIXML kun je elk object van 1 naar de andere PC doorsturen, of met PS remoting gewoon elk object op elke pc gebruiken en met Modules stream vanuit de PS sessie heb je 1 single source of modules die altijd met je mee reist naar elke ander server of PC.

Als jij native Unix bent ga dan niet PS proberen net zoals een Windowd beheerder geen python gaat gebruiken om zijn loginscripts te maken.

[Reactie gewijzigd door Scriptkid op 7 juli 2025 10:56]

[readefries]

Het idee heeft veel potentie, alleen zie ik dat POSIX shell scripts veel breder in te zetten zijn en veel robuster zijn. Leuk dat je met objecten kan gooien, maar in een script omgeving wordt het er niet ovetzichtelijker of duideleker van. Schrijf echte code als t nodig is, ms wil met pwsh werelden samenvoegen die in mijn ogen kwa gebruik en beheersbaarheid beter kan scheiden

[Caelorum]

Die shell scripts zijn vaak ook al decennia lang in ontwikkeling. Dat haal je niet zo snel in.

Toch prefereer ik Powershell boven bash voor alles wat enigszins complexer is en waarvoor ik niet wil gaan kopen compilen.

[Rinzwind]

PowerShell is overengineered. Niet geschikt voor systeembeheerders waar het eigenlijk voor bedoeld was en niet intuïtief voor programmeerders door bepaalde niet standaard keuzes. Plus draait het een en ander vaak trager en veel minder efficiënt dan oplossingen elders. Ook meer risico op stuk gaan script bij updates. Nee, nooit een fan geweest van PowerShell. Maar goed, alles wat Ms pushed en predikt wordt snel klakkeloos aanvaard in Ms omgevingen. Niet zo vreemd dat er op Linux niemand mee bezig is.

[michelr]

ro8in moet eens wat verder kijken dan zijn neus lang is; PS6 & 7 zijn cross-platform, draaien op Win/*nix/MacOS. Verder, welke Unix shell heb je het over? Bourne? Korn? C? etc. Elk met zijn eigen perks en eigenaardigheden. MacOS shell is btw gebaseerd op BSD, maar dat terzijde.

[latka]

Ik moet de eerste Unix bak met Powershell nog vinden in de praktijk. Het is ook redelijk kansloos aangezien in Unix 'alles is een file' de rol van het objecten aanspreken van Powershell op windows vervult. Als je script al werkt op Unix dan is er geen tool waar je wat mee kunt want 'alles is een file'.

[michelr]

Als het al werkt, prima. Maar voor nieuwe generaties zijn sed en awk wellicht een stuk minder intuïtief dan "object-gebaseerd" werken met properties en methods. En eerlijk is eerlijk, moet de eerste klant nog tegenkomen waar PS gebruikt wordt op een linuxomgeving.

[Guru Evi]

Als je object properties wilt dan is er jq of yq op Unix systemen en gelijkaardig voor XML of andere documenten.

[Blokker_1999]

Totdat je met bijvoorbeeld Azure begint te werken en je Azure wenst te kunnen configureren en beheren vanop je Linux laptop, of bijvoorbeeld als je met IaC bezig bent en gebruik maakt van Terraform op een Linux node of je CI/CD is volledig op Linux gebouwd. Dan ga je ineens netjes PowerShell installeren, laad je de nodige modules in en ben je zo vertrokken.

PowerShell is GEEN vervanger voor de command shells van *nix systemen, het is een CLI voor het beheer van Microsoft producten.

[MainframeX]

Het is op Azure helemaal niet nodig om Powershell te gebruiken. Je kan daarvoor in de plaats az cli gebruiken (ook van MS zelf) wat meer gericht is mensen die een unix/linux achtige shell workflow gewend zijn.

[Mellow Jack]

Ik heb 1000+ Linux VM's gezien waar Powershell gewoon beschikbaar was. Enorm handig in omgevingen waarbij leveranciers Powershell first ontwikkelen. Veel leveranciers updaten hun API's waarbij hun Powershell modules ook gelijk een update ontvangen. De Python sdk's volgens vaak pas later.

Dit is wel aan het veranderen. Bij bijv VMware zie je dat bijv de GO Library steeds beter word onderhouden. Misschien de Python library tegenwoordig ook maar die heb ik al lang niet meer geprobeerd

[sfranken]

MacOS shell is btw gebaseerd op BSD, maar dat terzijde.

Nee. De kernel van MacOS heeft delen van BSD, maar de shell was bash en is tegenwoordig zsh

[readefries]

Bash op macOs id oojk gewoon v2, enige dat quirky is op mac is dat ze BSD en GNU tools doorelkaaar gebruiken. Denk b.v. aan sed die daardoor niet compatibel zijn. Zo heb je meer tools die dan net andere vlaggen of gedrag hebben.

[Blokker_1999]

Windows is geen Unix variant, dus waarom jezelf laten beperken door Unix like shell? PowerShell is expliciet ontworpen om met Windows te werken en kan alles binnen Windows ook gewoon aanspreken en beheren. In tegenstelling tot een Linux heb je geen aparte tooltjes nodig om bijvoorbeeld configuratieparameters aan te passen of moet je niet in tekstbestanden werken. Alles doe je met cmdlets in PS. Dat is een fundamenteel verschil dat terug te brengen is tot de basis van het OS.

En alle cmdlets hebben een benaming in de vorm van verb-noun. Je weet dus altijd wat je gaat doen en waarop je het gaat uitvoeren. De documentatie van de standaard PS Modules is ook zeer goed en die modules zorgen net voor een enorme flexibiliteit. Dat heb je allemaal niet op een *nix systeem.

Op *nix begint het al met welke shell je gebruikt. Want je hebt niet zomaar 1 opdrachtprompt daar. Je hebt bash, sh, zsh en zovele meer. En ze hebben allemaal hun eigen verschillen en eigenaardigheden. Maar die shells zijn ook lege dozen waarbij je dus continue andere programma's gaat aanroepen om iets gedaan te krijgen.

Je doet alsof macOS iets speciaals doet om je wel die Unix like experience te geven, maar macOS X werd bij introductie zelfs gecertificeerd als een Unix besturingssysteem. Geen idee of het dat vandaag nog is. Maar de onderliggende BSD achtige kernel en de basis toolset maakt dat het gewoon een OS is waarop mensen die gewoon zijn van met *nix te werken, er relatief eenvoudig mee wegkunnen.

Het grote probleem is dus dat jij iets wenst wat PowerShell niet is. PowerShell is de command line interface voor alles wat Microsoft is. Net als je Docker CLI er is voor je Docker installatie.

En kon je voor PowerShell en WSL dan wel simpel uit de voeten met Docker op je Windows platform? Natuurlijk niet, Docker bestond toen nog niet eens. Maar is het de schuld van Microsoft dat Docker geen goede CLI heeft op het Windows platform? Ik zou daarvoor eerder naar de Docker devs kijken.

Ga op zoek naar de juiste tool voor de job. Is dat Linux? Gebruik dan Linux. Is dat Windows? Gebruik dan Windows. Is dat een mac? Gebruik dan die mac.

[readefries]

Op *nix begint het al met welke shell je gebruikt. Want je hebt niet zomaar 1 opdrachtprompt daar. Je hebt bash, sh, zsh en zovele meer. En ze hebben allemaal hun eigen verschillen en eigenaardigheden. Maar die shells zijn ook lege dozen waarbij je dus continue andere programma's gaat aanroepen om iets gedaan te krijgen.

Daar heb he een shebang voor, die je trouwens ook gewooon in pwsh files kan gebruiken, erg handig om ze crossplatform te kunnen gebruiken. Niet vergeten het bestand uitvoerbaar in te checken 😉

[Blokker_1999]

Uiteraard, maar wat ik vooral wil aangeven is dat er niet zoiets bestaat als de Linux of Unix shell. Het zijn ook gewoon allemaal verschillende shells met hun eigen syntax en eigen eigenaardigheden.

[Scriptkid]

En de power van pwsh is natuurlijk 1:many.


Je kunt met 1 beheer runspace in paralel 1000 vms aan sturen met het zelfde script of het nu windows, Linux of Mac is.

[beerse]

In jouw epistel raak je heel veel zaken die ver buiten powershell gaan. Dat zijn allemaal operating systeem zaken die buiten de taal en de tool zitten.

Powershell mag ik zelf graag vergelijken met perl en dergelijke script talen. Natuurlijk gaat dat overal mank maar primair zijn perl en powershell script talen die best wel gestructureerd in elkaar zitten.

Wat mij betreft kan je powershell onder msWindows ook wel vergelijken met de diverse shell-varianten die onder linux en unix beschikbaar zijn.

De kernel en containers zoals docker zijn zaken die ver buiten de taal powershell liggen. Ook bij unix en linux zijn dat zaken die niets met de shell of script talen te maken hebben. Als het om containers gaat en het trekt onder msWindows richting wsl dan heb je het container concept niet echt begrepen. Onder msWindows zijn tot op zekere hoogte wel containers mogelijk maar dan moet je wel beseffen dat het msWindwos systemen zijn die in containers draaien. Wil je unix of linux achtige zaken in een container draaien dan moet je een unix of linux platform gebruiken. Vanaf msWindows zijn wsl1 en wsl2 dan mogelijkheden met elk hun eigen nadelen. Andersom kan ook, daar gebruik je onder linux bijvoorbeeld een wine omgeving voor. Maar gezien msWindows zelf geen sandbox of `chroot` of zo iets kent, moet je dat ook zelf regelen.

[downtime]

Toen het ooit uitkwam was ik het zeker eens met dat Windows heel hard een echte terminal nodig had met meer mogelijkheden dan de dos prompt. Echter waar ze mee kwamen was een shell waar ik echt alles moest leren bijna vanaf het niveau alsof ik voor het eerst een computer aanraak. Daarbij helpt het niet mee dat commando's opmakende dan uit de paar keer dat ik het geprobeerd heb gewoon totaal geen logische benamingen hebben. Het is een overcomplex ding waar ik afgezien van de standaard dos prompt commando's ik echt geen idee heb van wat ik moet invoeren om iets gedaan te krijgen.

Dus je hebt het "een paar keer" geprobeerd, het was anders dan je gewend was, en nu wil je er niks meer van weten? PowerShell is feitelijk een object georienteerde scripttaal die meer op VBS, Ruby of Python lijkt dan op een simpele shell. Als je alleen maar een shell zoekt dan zou ik het inderdaad overkill noemen want om er optimaal gebruik van te maken moet je wel wat tijd erin steken.

Waarom niet gewoon een Unix like shell zoals elk ander OS wat zich al jaren bewezen heeft zo een beetje tot perfectie te voorzien in alles wat je van een Terminal zou willen?

Laten we vooral nooit wat nieuws proberen. Waar is het goed voor? Waarom een auto leren rijden als paard en wagen zich al jaren bewezen hebben?

MacOS heeft gewoon een Unix shell waarbij ik bijna wel voor 99,9 procent kan zeggen dat wat ik op Linux doe ook altijd op MacOS kan. Met WSL is dat echt wel een ander verhaal en toch wel situaties gehad welke dan gewoon simpelweg niet werkend waren te krijgen op WSL.

Geen wonder. MacOS is ook gewoon UNIX. Is gecertificeerd als UNIX en is deels op FreeBSD code gebaseerd. En Microsoft zal nooit UNIX zijn om de eenvoudige reden dat backwards compatibility het bedrijf zo succesvol heeft gemaakt.

Powershell zoals het is is gewoon een beheer commandline tool voor ITers die met Microsoft spul werken. Maar verder heb je er niks aan.

Ahum. Als PowerShell alleen maar "een beheer commandline tool voor ITers die met Microsoft spul werken" is, dan is het al een succes. Want dat is een hele grote groep. De simpele eindgebruiker wil gewoon een GUI. De professionals willen kunnen scripten, liefst in een taal die ze ook in de terminal kunnen gebruiken, en Powershell is een geweldige scriptingtaal die specifiek voor die groep is ontwikkeld.

Sorry verder onrelevant tot het nieuws dat Microsoft stopt met Powershell 2, beter stoppen ze er helemaal mee en integreren ze gewoon een native Unix compatible shell zodat Windows misschien weer een beetje kan functioneren als het OS waar je gewoon alles mee kan.

Ze hebben een Unix compatible shell. Die heet PowerShell 7. Ik draai het naar volle tevredenheid op Linux. Maar blijkbaar heb je niet opgelet en blijf je liever in de jaren 70 steken.

En een project als Nushell bestaat niet voor niets. Dat is gewoon PowerShell maar-dan-anders. Blijkbaar hebben sommige mensen wat meer behoefte aan innovatie dan jij.

[Pep7777]

Een verhaal (rant eigenlijk), maar niet informatief of nuttig en soms zelfs incorrect, dus de +2 die je op dit moment krijgt begrijp ik eigenlijk niet (kan ook mijn probleem zijn ). Powershell doet het ook op linux, en het is een krachtige omgeving (waar met .Net/mono) je makkelijk plug-ins toevoegd. Ik zou er zeker weer eens naar kijken (en even je Windows blinddoek afdoen, want ieder OS heeft zo zijn voors en tegens). Maar powershelll heeft mij al heel veel opgelevert om zaken te automatiseren.

[GertMenkel]

PowerShell heeft een syntax die alleen een moeder mooi kan vinden, maar als scriptingtaal is het krachtiger en eerlijk gezegd beter dan de gangbare Unixscripts.

bash, zsh, csh, POSIX sh, ze zijn allemaal minder krachtig. Hun control flow bestaat grotendeels uit trucjes die backwards compatible zijn met hacks om if statements uit te voeren zonder echte scriptingtaal. PowerShell heeft klasses/structs en type-informatie, conversies, en operaties zonder hele nieuwe scripttalen te hoeven leren (awk/grep/sed/jq).

Er zijn Linuxshells (sommige waarvan ook op de *BSD's werken) die PowerShell's betere objectmodel overnemen, maar veel daarvan gebruiken slechts tussenvormen (bijvoorbeeld door alle data op te slaan in JSON).

Gooi het gemiddelde "UNIX"-script door shellcheck of een soortgelijke tool en je zult tientallen bugs vinden. Er zijn geen pad-API's, er zijn slechts (optionele) programma's die (als het goed is) een string uitpoepen op basis van een string die je doorgeeft. De hele bende zit, net als command.com en cmd.exe, in elkaar met duct tape, tiewraps, en goede hoop. POSIX shell kan niet eens twee getallen bij elkaar optellen, en daarom heeft iedere afgeleide daarvan hun eigen (afschuwelijke, vaak incompatible) syntax om dat voor elkaar te krijgen.

Overigens heb je altijd al gewoon bash kunnen downloaden op Windows. Het werkt net zo goed als op Linux. Je hebt er niet eens iets van wsl2 of cygwin voor nodig, maar pas als je bash zonder cygwin gebruikt, heb je door hoe beperkt de "Unix"-shells eigenlijk van zichzelf zijn.

De syntax van PowerShell is en blijft foeilelijk, al is dat ook weer niet zo heel erg als het alternatief bestaat uit het lijmen van programmanamen als [[, ps, sed, awk, ls en bc, maar het is een superieure shell.

[downtime]

Ben het helemaal met je eens. Moest vorig jaar na jaren in PowerShell iets simpels in bash maken. Ik voelde me meteen weer helemaal terug in de jaren 80, batch files makend in MSDOS, want voor zoiets simpels als variabelen moet je weer, net als vroeger, op string substition terug vallen. En iets anders dan strings kent het niet. PowerShell mag dan een learning curve hebben, maar dan zit je ook in een moderne taal te programmeren, en zit je niet alleen maar een stelletje workarounds en hacks te managen.

[Firestorm666]

PowerShell vindt ik juist erg gemakkelijk in vergelijking. Persoonlijk vindt ik de structuur er logisch uitzien en de commands zijn ook "leesbaar".

En geen flauwe kul zo als een spatie ergens verkeerd zetten dat je hele script breekt.

[GertMenkel]

Leesbaar is relatief . Je moet maar net weten wat Get-Child, Get-Member, en Select -ExpandProperty doen, uit de naam haal je het niet direct. Maar goed, het is ook weer niet complexer dan de syntax van awk of jq, alleen meer typwerk.

[Davey400]

Lol, jouw betoog klinkt als mijn leven, maar dan vanaf de andere kant bezien.

Groot geworden met Commodore-basic* (toevallig ook van Microsoft, maar dat zei me toen nog niks). Daarna op de pc naast natuurlijk de onvolprezen batchfiles naar GW-Basic, en door naar Quickbasic voor complexere zaken.

Tussenstapje naar KiXtart. Jahoe, een 3rd party tool (maar wel van/door een MS medewerker, Ruud van Velsen) die in begrijpelijke taal mooie dingen kon doen.

Toen kwam vbScript. Weliswaar geen Shell, maar wel heel krachtig. Deze drukte Kix weer naar de achtergrond. Ondertussen nog steeds veel batchfiles ook, waar het kon.

En daar was Powershell. Nieuwer en beter. En weer een shell, want dat was beter dan vbScript. Ik moest wel lachen, want ik hing ook nog steeds veel in de batchfiles, dus ik zou wel zien wat er van dat nieuwe ding kwam. Het was in ieder geval inderdaad een behoorlijke stijle leercurve en tot niet eens zo heel lang geleden greep ik voor echt ingewikkelde scripts nog steeds naar vbScript. Daar een jaar of 2/3 geleden toch maar eens mee gestopt.

Maar dan komt mijn punt: ik ben dus best wel redelijk thuis in de shells en scripting binnen de Microsoft portfolio. Maar als ik dan een keer dingen op mijn netwerk-componenten of Home Assistant moet doen in de shell dan sta ik weer volledig hulpeloos en met mijn bek vol tanden te staren naar wat ik moet doen, en ben ik heel dankbaar met de huidige ontwikkelingen van de diverse taalmodellen.

Dat ligt niet aan Linux, dat ligt volledig aan mij en mijn onkunde. En mijn vastgeroest patroon in het Windows-ecosysteem. Er is voor mij dan ook geen enkele reden om Linux af te fakkelen omdat ik de shell te complex vind. Er is gewoon een markt voor beide stromingen, en de kans is groot dat dat zo zal blijven.

(Al steken de geruchten dat ook MS naar de Linux kernel kijkt als basis voor de Windows GUI nog steeds regelmatig de kop op.)

_{*en een beetje assembly 🤓}

[WillySis]

Als ik je reactie lees, dan lees ik de woorden van een verstokte Linux / Unix gebruiker. Windows is gewoon niet voor dit type gebruiker bedoeld. Je kan wel veel commentaar leveren, maar eigenlijk ben je met Windows compleet aan het verkeerde adres.

Powershell geeft enkele krachtige mogelijkheden, maar meer dan 90% van de gebruikers zal Powershell nooit gebruiken. De Powershell is bedoeld voor een aantal beheersfuncties die voor een deel ook vanuit een grafische omgeving uitgevoerd kunnen worden. De rest is meer voor systeembeheerders. Windows is bedoeld als grafische omgeving voor consumenten en kantoor om programma's op te draaien. Er zijn aan wat grafische toeters en bellen toegevoegd om het visueel aantrekkelijk te maken, maar hoewel Unix wel de basis is geweest, is het nooit de bedoeling geweest om Windows te kunnen gebruiken alsof het een Linux / Unix machine is.

[Guru Evi]

PowerShell is vooral niet compleet als het komt op een scripting taal voor beheer.

Er is nog heel veel die gewoon “roep WMI aan” of “roep COM aan” en dan moet je de syntax en structuur van die oude Microsoft tools al kennen. En als WMI het niet heeft (vb audio volume of resolutie van je scherm) dan heeft PowerShell het ook niet, moet je al zitten prutsen met modules van iemand anders of C# in PowerShell schrijven. Mag ik evengoed in DOS batch zoals vroeger nircmd en pstools aanroepen. Tussen die 2 developers zitten meer krachtige tools dan heel PowerShell samengeraapt.

[Reactie gewijzigd door Guru Evi op 6 juli 2025 13:30]

[WillySis]

Ik beweer ook niet dat PowerShell compleet is.

[Glashelder]

Alsjeblieft niet zeg. Als je goed met Powershell overweg kan dan wil je echt nooit, maar dan ook nooit meer terug naar string based scripts zoals in bash.

Dat is net zoals vanaf C# overstappen naar PHP Niemand in de geschiedenis van de mensheid heeft dat ooit vrijwillig gedaan. Met goede redenen. Objecten > String based.

[bluesgold]

Beste,

Powershell is DE tool voor een Windows systeembeheerder.

Ik doe gewoon alles met powershell.

Van vms aanmaken, azure vms, 365 beheer, ad beheer, file server beheer, Citrix beheer, avd management, .....

Dus Neeee, geen Linux powershell !!!

Liefst powershell 7.

Grts

[jimshatt]

Behalve dat het verhaal over Docker offtopic was, soit, vraag ik me toch af wat er bij jou mis gaat als je Docker in WSL installeert met apt install. Bij mij werkt dat prima. Je kunt op je windows omgeving nog even docker-cli installeren en als je DOCKER_HOST goed zet kun je zelfs je locale cli gebruiken om Docker te besturen.

Maar goed, dit heeft helemaal nikst te maken met Powershell natuurlijk.

[youridv1]

Echter waar ze mee kwamen was een shell waar ik echt alles moest leren bijna vanaf het niveau alsof ik voor het eerst een computer aanraak.

Dus het is slecht omdat het een leercurve heeft en niet op bash lijkt? Interessant standpunt.

Waarom niet gewoon een Unix like shell zoals elk ander OS wat zich al jaren bewezen heeft zo een beetje tot perfectie te voorzien in alles wat je van een Terminal zou willen?

Omdat Windows niet Nix achtig is. En unix shells zijn helemaal niet perfect. Ze zijn een ongeordend samenhangsel van commando's, talloze losse binaries voor de meest basale functies en het editten van 1000 config files waarvan je uit je hoofd moet weten waar ze staan.

9/10 keer als je iets complex moet configureren in een Unix systeem doe je dat helemaal niet in de shell. Je edit een config file. Het enige wat de shell doet is het uitvoeren van systemctl restart en zelfs dat is niet meer dan het callen van een binary.

Waarom zou Powershell moeten integreren met Unix tooling? Daar gaat niemand het voor gebruiken. Ga maar eens met een beheerder praten die Powershell gebruikt voor het automatiseren en deployen van Windows bakken. Het is bizar krachtig.

Je gehele comment kun je samenvatten als: Het sluit niet aan op mijn usecase en mijn ervaring met unix vertaalt zich niet 1:1 en dat vind ik kut.

[Reactie gewijzigd door youridv1 op 7 juli 2025 12:14]

[lordsnow]

Zijn nieuwere versies van PowerShell dan niet backward compatible? Want zo klinkt het...

[rko4u]

Je zou het verwachten, maar zo klinkt het voor mij juist niet! Want dan was er geen enkele reden geweest om op versie 2 te blijven hangen.

[downtime]

Vrijwel 100% compatible, voor zover ik heb gemerkt. Maar de noodzaak om een 2.0 script te testen voordat je het op 5.0 draait is er wel.

De stap van 5.0 (op basis van .NET Framework) naar 6.0 (op basis van .NET Core) en daarboven is een stuk groter. Dan is er een grote kans dat je scripts moet aanpassen.

[Blokker_1999]

Ze zijn backward compatible in die zin dat je dus kon terugschakelen naar een vorige versie wanneer noodzakelijk. En PS5 heeft over het algemeen geen problemen met de meeste PS2 scripts, al zullen er ongetwijfeld uitzonderingen zijn. De grotere breuk zit in wat er na versie 5 is gekomen. Want tot en met versie 5 maakte men gebruik van .NET, in versie 6 is men naar .Net Core overgestapt waardoor er aan de ene kant cross platform mogelijkheden ontstonden (PowerShell op Linux) maar aan de andere kant bepaalde functionaliteit wel verdwenen is.

[biomechanical]

Waarschijnlijk met dezelfde "backwards compatibility" in windows waarvan men maar moet hopen dat deze werkt.

Ikzelf heb deze "backwards compatibility" Wel eens nodig gehad maar de resultaten waren dermate slecht dat ik de software maar heb vervangen. Zoveel software heb ik niet, nog was deze software duur. Maar een bedrijf zal hier waarschijnlijk niet blij mee zijn.

[IStealYourGun]

Ik raad je aan om eens wat blogs te lezen van the old new thing rond backward compatibility. Er kom daar veel bij zien en vaak faalt het door de ontwikkelaar van de sofware en niet door Microsoft, en toch geven mensen Microsoft de schuld voor hun buggy software.

[wildhagen]

In plaats daarvan kwam PowerShell 5.0, wat de huidige versie is, en inmiddels is er ook PowerShell 7.0 met nog meer features

Ja, meer features, en dat is heel mooi uiteraard. Maar helaas zijn er in Powershell 7 (en ook 6) ook diverse switches van bestaande commando's verwijderd, die wel in 5.x zaten. Dus niet het statement zelf, wat er nog wel in zit, maar bepaalde switches van het statement.

Klinkt triviaal, maar als je scripts hebt die die switches hard nodig hebben, werken je scripts dus niet meer met PS7 zonder alles aan te passen. Nog niet zo'n probleem met één script, maar als je er honderden hebt....

Het is jammer dat Microsoft op deze manier de backwards compatibility sloopt zonder dat er een deprecration periode is geweest (waarin je je proactief kon aanpassen) voor het schrappen van die switches en je er dus proefondervindelijk achter moet komen....

Dat PS2.0 nu verdwijnt is dan imho op zich geen probleem en begrijpelijk. Die is inmiddels wel érg oud, en al jarenlang bekend dat het zou worden verwijderd.

[DdeM]

Moet zeggen dat voor mij powershell 7 altijd een van de eerste tools is die ik installeer. Heb om een of andere reden altijd ruzie gehad met ps5 met zaken als rechten die ik met ps7 nooit heb. Snap aan een kant ook niet dat niet beide standaard in windows zitten zodat je makkelijk ps7 kan ondersteunen voor install script ea zonder die eerst nog óók binnen te moeten halen. Zou migratie ook makkelijker maken.

[Caelorum]

Sowieso, ik maak vaak scripts voor in build pipelines en dan is Powershell 7 wel een stuk handiger, omdat het redelijk platform agnostisch is. Een PS7 script draait vrijwel zeker ook in Windows als het onder linux werkt.

PS5 mag wat mij betreft afsterven.

[xFeverr]

Snap aan een kant ook niet dat niet beide standaard in windows zitten zodat je makkelijk ps7 kan ondersteunen voor install script ea zonder die eerst nog óók binnen te moeten halen. Zou migratie ook makkelijker maken.

Als dit in Windows zou zitten, dan moet het ook de support lifecycle van Windows volgen. Het .NET-team wilde dat bijvoorbeeld niet meer, die willen sneller gaan. En dat zal met PowerShell Core ook zo zijn, zeker omdat het ook sterk leunt op .NET

En ook als je multiplatform gaat, dan kan je support lifecycle ook niet vasthangen aan slechts één van die ondersteunende OS’en. Ze hebben allemaal hun eigen lifecycles en cadans. Lekker loshouden is dus het beste in dat geval

[cyble]

Meestal zijn het maar een paar specifieke commando's, dan zou ik een wrapper maken en die aanroepen of een python scriptje die al dan niet met AI de scripts aanpast.

unpopular opinion warning

Je kunt er nooit vanuit gaan dat iets met externe dependencies in een niet volledig gesloten en verzegeld systeem tot in de oneindigheid blijft werken.

Meestal zijn dit soort momenten ook een goed moment om te herzien of je het nog nodig hebt en of het handiger kan.

En een uitfaseringsmogelijkheid van v2 naar v7 had toch genoeg tijd moeten zijn alvast te upgraden naar een hogere versie vóórdat het echt end of life is. Spoiler: heb je nog scripts onder powershell 3: tijd om te upgraden voordat het te laat is!

[Reactie gewijzigd door cyble op 5 juli 2025 11:55]

[GertMenkel]

Hoewel je niet volledig ongelijk hebt, vind ik het wel raar dat PowerShell switches weghaalt voor ingebouwde functies in nieuwere versies.

Dat bepaalde operaties en aliassen weg zijn merk je meteen, maar optionele switches die verdwijnen veranderen gedrag van bestaande functionaliteit en zijn ook niet zo 1-2-3 uit een programma te pikken.

Hoe dan ook lijkt het me verstandig om te upgraden voor het te laat is (alhoewel PS5 nog wel even in support blijft verwacht ik), maar zulk gedrag wekt wel wantrouwen op van gebruikers en dat had MS beter moeten doen.

[Alfa1970]

Hoe bedoel je beter moeten doen, ze waarschuwen al meer dan 5 jaar lang dat het gaat verdwijnen, waar houdt het op?

En het is niet zo dat je powershell 2.0 niet meer kan gebruiken, het zit alleen niet meer standaard in een nieuwe installatie van Windows 11 meegeleverd, alles wat je op dit moment hebt blijft het gewoon doen.

Dus je hebt nog steeds tijd om uit te zoeken wat wel en wat niet meer werkt.

En misschien kun je ook meteen kijken naar de reden waarom iets niet meer kan, misschien is het wel omdat dat overbodig is geworden omdat er iets makkelijker en beters is.

[GertMenkel]

Normaal zou je voor een scriptingtaal als deze backwards compatibility toevoegen. De manier waarop MS van CLR naar Framework naar Core gaat, maakt dat weliswaar moeilijk, maar dit is een keuze die MS zelf tijdens het ontwerpproces gemaakt heeft. Zelfs als je op objectniveau geen compitabiliteit kunt garanderen, kun je op zijn minst de switches nabouwen zoals ze ook in de vorige versie zaten. Dingen als VBS en JScript heeft Microsoft jarenlang compatible gehouden met vorige versies, en zelfs VBA doet het nog prima (op wat gedocumenteerde beveiligingstoevoegingen na) met de decennia oude macro's.

Microsoft heeft geen concrete EOL-datum voor PS5.1, dus daar kan je je lastig op voorbereiden. PowerShell 2.0 is overigens al uit support en Microsoft geeft geen garanties dat het werkt of veilig is; als je nog iets lager dan 2.0 gebruikt, ben je eigenlijk te laat met het inzetten van een upgradepad.

En ja, wellicht zijn er nieuwere, betere, makkelijkere manier bijgekomen om dingen te doen, maar als je een collectie PowerShell-scripts van tientallen tot honderden regels hebt, kost het testen en herschrijven daarvan tijd. De nieuwe trucjes zijn leuk als je ze in de console gebruikt, maar PowerShell is bij uitstek een scripttaal.

PowerShell is eigenlijk de enige scripttaal die ik ken die backwards incompatible is bij nieuwe releases. Dat komt wellicht gedeeltelijk omdat de meeste andere scripttalen niet zoveel kunnen, maar het is wel bijzonder onhandig.

[Reactie gewijzigd door GertMenkel op 5 juli 2025 19:43]

[Alfa1970]

Die transitie heeft vele jaren geduurd dus mensen hebben dat aan zien kunnen komen. Backward compatibiliteit kan vernieuwing in de weg zitten. Het doel wat men wil bereiken kan mogelijk niet bereikt worden door vast te houden aan enkele oude zaken. Het gewenste is wellicht nog steeds mogelijk, maar zal op een andere manier moeten worden bewerkstelligd.

Dat een EOL datum niet beschikbaar is wil niet zeggen dat je geen onderzoek kunt doen ter voorbereiding op de transitie die noodzakelijk is. Nieuwere versies bestaan al enige jaren, en er zijn verschillen.

Met het schrijven van software voor een bepaald doel maak je jezelf afhankelijk van de omgeving waar je die software voor schrijft. Als die omgeving verandert (i.e. er komt een nieuwere versie van x uit) dan zul je je eigen software moeten her-evalueren.

Als je niet wil meegaan en je wilt geen enkele verandering, dan moet je het hele systeem "bevriezen" en nooit ook maar ergens van een nieuwere versie installeren. Alleen dan kun je er zeker van zijn dat de software blijft functioneren zoals die was.

Installeer je updates, dan zul je met jouw software mee moeten gaan in de tijd en je aanpassen voor die zaken waarvan je afhankelijk bent.

Python had ook een grote compatibiliteit break tussen versie 2 en versie 3, dus het is niet ongehoord dat backwards compatibiliteit is opgegeven ten faveure van vooruitgang.

Niet meebewegen met je omgeving is een recept voor problemen. Is het vervelend? Zeker. Maar het is niet iets dat als een donderslag bij heldere hemel is gekomen, het is een ontwikkeling die al jaren aan de gang is. Stilstand is achteruitgang en dat geld op alle niveaus, ook op het niveau van scriptjes.

[GertMenkel]

Python is precies het schoolvoorbeeld van hoe het misging. Nog steeds heb ik ergens een kopie van Python 2 liggen omdat niet iedereen interesse heeft in het porten van hun software en ik ook geen zin heb om andermans open source Pythonproject te herschrijven. Om diezelfde reden installeert men nog steeds Powershell 2.0, een versie die al lang niet meer ondersteund wordt, op Windows 11 machines. Lijkt me toch exact wat je zou willen voorkomen als. Microsoft zijnde.

Ik vraag ook niet om een bytecode compatible runtime, gewoon "dezelfde opties in je cmdlet of functie aanbieden die je al tien jaar aanbiedt zodat niet iedereen ieder script regel voor regel moet nalopen om te kijken of de nieuwe versie het kapot maakt". Microsoft heeft in Windows 11-programma's nog switches zitten die uit het OS-tijdperk komen dus zo'n enorme last is het ook weer niet.

Als je scripts toch moet gaan herschrijven, zie ik niet waarom je nog een keer voor Powershell zal gaan. Ga dan over op Python ofzo, dan hoef je je scripts niet iedere paar jaar te herschrijven, en het maakt een potentiële overstap naar iets als macOS in de toekomst alleen maar makkelijker.

[Alfa1970]

Scripts hoeven niet herschreven te worden, er zijn kleine veranderingen tussen versie x en versie x + 0.1. Het basis principe van de code blijft overeind je hebt variabelen voor data structuren, je hebt conditionele voortgang en je heb lussen naast lineaire voortgang. Die principes bestaan in elke C derivatieve programmeer taal en die zullen ook niet weg gaan, het zijn specifieke argumenten voor specifieke objecten of functies die veranderen omdat de onderdelen waar die functies of objecten mee moeten praten veranderen.

Een probleem zoals dit ontstaat echter doordat de schrijver de software niet bijhoudt waardoor het gat tussen de verouderde software en de nieuwere omgeving steeds groter wordt.

Ook Python scripts zijn onderhevig aan onderhoud. Als je te lang wacht met het meegaan in de tijd, dan kun je er zeker van zijn dat de code op een gegeven moment niet meer functioneert. Dit is een fenomeen dat ik al jaren mag aanschouwen. Ik ben continue bezig met het doornemen van de releasenotes van software waarmee de Python code moet samenwerken omdat er continue kleine veranderingen zijn, die als je ze laat voor wat ze zijn op een gegeven moment een probleem gaan veroorzaken.

Dit is niet een Python probleem, of een Powershell probleem, dit is een probleem met degene die de software onderhoud of zoals in dit geval het gebrek aan onderhoud.

Als je denkt dat het op een Mac anders is, dan nodig ik je uit om te proberen. Je bent misschien niet oud genoeg om de hele geschiedenis meegemaakt te hebben.

Of misschien ben je het gemakshalve vergeten. Maar MacOS is "recent" maar liefst 3 maal van hardware platform verandert waardoor alles volledig herschreven diende te worden.

De ontwikkeling van software stopt niet bij het schrijven van de laatste regel code. Het is een continue proces van vernieuwing om de software relevant te houden. Dit is noodzakelijk omdat de omgeving waarin die software "leeft" ook verandert.

[latka]

Daarom: schrijf batch files. Doen het al tientallen jaren zonder aanpassingen.

[downtime]

Klopt. Want daar is al tientallen jaren totaal geen innovatie meer geweest. Ik maak voor simpele dingen nog wel eens een batch file, want lekker simpel, en elke keer heb ik er spijt van en herschrijf ik het script later in PowerShell omdat die scripts altijd uitdijen, en complexer worden dan je oorspronkelijk van plan was, en voor complexere zaken loont het echt om gewoon PowerShell te gebruiken.

[SPee]

En toch, decennia nadat we Powershell hebben, zie ik het nog maar weinig gebruikt worden.

Meeste scripts hebben .CMD, .BAT of .sh als extensie. Ik denk dat er veel ontwikkelaars geen idee hebben dat ze ook een .ps of .ps1 kunnen uitvoeren.

[downtime]

Serieus? Waar werk je dan? Eerlijk gezegd, als een ontwikkelaar op het Windows platform na al die jaren nog niet weet wat PowerShell is, dan vrees ik dat ie ook al 20 jaar stil staat in z'n ontwikkeling en beter met pensioen gestuurd kan worden.

[The-Source]

Op moment dat je dus niet een ps script aan taskbar kan koppelen als snelkoppeling en een batch script wel blijf ik het toch af en toe nog gebruiken al is het maar om via batch dus het nodige Powershell script aan te roepen.

Helaas is dat de Windows logica waar je af en toe mee te maken hebt.

Zo ook het gebrek aan rsa ondersteuning in PS5.0 zijn sommige script verplicht ps7

[SuperDre]

Batch files of powershell scripts... Appels met peren vergelijken. Batch files zijn zo extreem beperkt ten opzichte van powershell scripts.

[latka]

Beide zijn turing compleet dus alles wat de ene kan kan de ander. Of sommige dingen korter te noteren zijn in de een dan de ander is iets anders.

[SuperDre]

Dan vraag ik me af wat jij batch files noemt, zeker daarnaast dan nog een heleboel extra applicaties en frameworks als python geinstalleerd.

[Blokker_1999]

Maar die deprecation periode is er toch net wel? PS5 zit nog altijd in Windows ingebakken en er is nog altijd geen datum bekend wanneer dat dat verdwijnt. Je kan dus alles wat je reeds had nog altijd gewoon uitvoeren en ondertussen nieuwe dingen beginne schrijven in PS7 terwijl je ook stilaan werkt aan de omzetting van je legacy naar de nieuwe PS variant.

PS7 is ook nooit voorgesteld als een drop-in replacement voor PS5 daar het een andere kerntechnolgie heeft wat ook de noodzaak voor de aanpassingen verklaard.

[SirBlade]

Dan maak je een powershell script om die scripts met depreciated switches en/of commandlets op te sporen.

[aikebah]

Die switches zijn overigens niet afgewaardeerd (depreciated), maar verouderd (deprecated)

[Raven]

"Het is jammer dat Microsoft op deze manier de backwards compatibility sloopt zonder dat er een deprecration periode is geweest (waarin je je proactief kon aanpassen) voor het schrappen van die switches en je er dus proefondervindelijk achter moet komen...."

Is er geen PowerShell-tegenhanger van Python's 2to3 tool?

[belal]

PowerShell 2.0 is een oude versie van de cli-tool. Het zat al in Windows 7, maar Microsoft liet bij Windows 10-versie 1709 weten dat PowerShell 2.0 werd uitgefaseerd. De tool kreeg toen de deprecated-status en zou niet meer worden bijgewerkt.

De laatste versie 1709 kwam uit in oktober 2017. Bijna 8 jaar daarna halen ze het weg.

[SuperDre]

Het is jammer dat Microsoft op deze manier de backwards compatibility sloopt zonder dat er een deprecration periode is geweest (waarin je je proactief kon aanpassen)

Maar die is er toch? Je kunt nu nog steeds gewoon 5 gebruiken en de script die niet met 7 werken gewoon aanpassen. En voor zover ik weet staat er in de What's new lijst gewoon welke parameters/switches veranderd zijn. Zou me niet eens verbazen als er een tool is die je scripts kan doorlopen om te checken wat niet meer zal werken.

Simpel verwachten dat alles nog werkt als je van 5 naar 7 gaat is wel heel erg naief. Net zoals je dat ook niet verwacht dat alles van powershell 2 zonder aanpassingen op 5 zal werken.

[Don Key]

Powershell.. de "net niet" shell scripting manier van Microsoft.
Alles aan powershell is net niet af, makkelijk, consistent, logisch in elkaar gezet.
het doet me vaak wat VBA achtig aan, vreemde oneliners, echt goed logische flows doen is een draak om te doen (als je programmeer kennis hebt iig)
Nee, ik vind het meer onhandig dan handig. (maarja dat vind ik van veel Microsoft tooling, het is het NET niet...)

Het (voor mij) gekke is dat veel niet programmeer ervaren mensen er wel redelijk mee overweg kunnen (net als het gruwlijke VBA (gelukkig stapt Microsoft daar ook vanaf en gaat naar Python)). Ik denk dan: HOE DAN?! Mss heb ik wel teveel gezien, om de gekkigheden van powershell op te merken.

[Reactie gewijzigd door Don Key op 5 juli 2025 12:59]

[downtime]

Powershell.. de "net niet" shell scripting manier van Microsoft.
Alles aan powershell is net niet af, makkelijk, consistent, logisch in elkaar gezet.
het doet me vaak wat VBA achtig aan, vreemde oneliners, echt goed logische flows doen is een draak om te doen (als je programmeer kennis hebt iig)
Nee, ik vind het meer onhandig dan handig. (maarja dat vind ik van veel Microsoft tooling, het is het NET niet...)

Geef eens wat voorbeelden. Want ik heb nu geen idee waar je het over hebt. Ik vind PowerShell af, makkelijk, consistent en heel logisch. Niet perfect, dat zeker niet, want elk voordeel heb nu eenmaal z'n nadeel, zoals de grote filosoof ons leerde.

[Don Key]

ga maar eens hetzelfde doen met een programmeertaal, en vergelijk de kronkels die je moet doen in powershell om hetzelfde te kunnen doen (van de dingen die het ondersteund). Je zult snel genoeg merken dat je tureluurs wordt van powershell zijn gekkigheden, vs wat een gedegen taal wel goed doet.
(bv c# vs powershell voor windows automation met wat niet erg complexe logica ingebouwen (loops, conditions etc)

zoals ik al zei, er zijn zat mensen die geen issues zien in powershell en er mee uit de voeten kunnen. Maar ik totaal niet (mijn brein kan het gewoon niet doorgronden, in tegenstelling tot diverse programmeertalen)

[downtime]

Je noemt nog altijd geen voorbeelden. Dus ik heb nog steeds geen idee wat je bedoelt.

[Don Key]

gevalletje, if you have to ask....

ik ga geen voorbeelden geven, ook niet nodig. je herkent het of niet.. anders krijg je welis nietus gedoe.

[Reactie gewijzigd door Don Key op 5 juli 2025 23:58]

[naaitsab]

Hoop dat de PowerShell ISE nog wel even blijft bestaan. De 'officiële' vervanger is VS Code met de Powershell addon maar dat vind ik, zeker voor kleinere scripts toch wel een erg lomp alternatief.

Mis nog wel een officiële lijst met functies en parameters die komen te vervallen. Heel veel 2.0 werkt ook gewoon op 5.0 maar zeker niet alles.

[HollowGamer]

Ik vind dat dit geen deel moet uitmaken van de core. Dat is het probleem van Windows, te veel oude spul, wat alleen maar ruimte en veiligheid issues met zich meebrengen.

Heb er niets op tegen dat sommige nog 2.0 gebruiken, op Linux kan je ook gewoon python2 installeren (of via een repo ergens).

[HollowGamer]

Misschien kunnen ze de oude UI-elementen ook eens verwijderen?

Gok dat dit niet gaat, aangezien daar ook te veel APIs aan hangen.

[Dark Angel 58]

Beter dat het altijd naar laatste versie moet updaten, begrijpt nog steeds niet waarom er meerdere versies tegelijk draaien.

[NLxDoDge]

Als alles backwards compatible is maakt het niet zoveel uit nee, maar als er bij elke grote versie veel code herschreven moet worden, dan kan ik je nu als software developer al vertellen dat veel bedrijven er dan voor kiezen om het zo te houden a.k.a. wat is het goedkoopst.

Gelukkig doen ze dat bij mijn huidige opdrachtgever niet

[Reactie gewijzigd door NLxDoDge op 7 juli 2025 13:55]

[MPAnnihilator]

op jump servers draaien soms wel 10 versch Java versies :)

[rko4u]

Restricties? Soms moet je verouderde software gewoon upgraden naar een recente versie.

[latka]

Want? Ik gebruik nog steeds awk voor het verwerken van grote files. Werkt al sinds jaar en dag overal altijd. Een schroevendraaier ga je toch ook niet herontwerpen omdat'ie oud is.

[downtime]

Een schroevendraaier ga je toch ook niet herontwerpen omdat'ie oud is.

Slecht voorbeeld. De hele wereld is namelijk op de "herontworpen" electrische schroevendraaier overgestapt.

[latka]

Volgens mij bestaan die gewoon naast elkaar... Andere tool andere doeleinden.

[rko4u]

Prima dat je oude software gebruikt, maar verwacht niet dat de maker oneindig oude versies blijft supporten. Het is niet dat je met 2.0 dingen kon die tegenwoordig niet meer kunnen. En dan is er vaak nog een optie om het zonder support te blijven gebruiken. Echter is dat vaak niet de veiligste optie.

[michelr]

Software is inderdaad geen one-off - nieuwe ontwikkelingen, nieuwe inzichten. Er is een lange weg bewandeld sinds WSH en PS1, en elke major release voegt zeker waardevolle elementen toe. Soms komen die uit "klassieke" omgevingen (classes) en soms handig. Bedenk dat PS ook gebruikt wordt door beheerders, dus moeten dingen niet altijd teveel over de developer as gaan om nuttig te zijn voor die doelgroep (eg runspaces vs -parallel)

[Reactie gewijzigd door michelr op 5 juli 2025 12:00]