Microsoft maakt PowerShell open source en beschikbaar voor Linux en OS X

Zoals een gerucht al suggereerde heeft Microsoft Powershell open source gemaakt en alfaversies voor onder andere Linux en OS X beschikbaar gemaakt. De verschillende versies van de ontwikkelaarsterminal zijn per direct te downloaden van GitHub.

Microsoft PowerShell-architect Jeffrey Snover maakt het nieuws op donderdag bekend op de Microsoft Azure-blog. PowerShell is direct te downloaden voor OS X 10.11, Ubuntu 14.04 en 16.04 en CentOS 7. De software is vrijuit beschikbaar onder de MIT-licentie. Microsoft besloot eind 2014 al .net, het framework waarmee PowerShell werkt, open source te maken. Anderhalve maand geleden bereikte de open source .net-core nog versie 1.0. Microsoft zegt het mogelijk te willen maken voor ontwikkelaars om dezelfde tools en programmeertaal te gebruiken op verschillende platforms.

Dat er gewerkt werd aan PowerShell-builds voor OS X en Linux was al bekend, maar een officiële aankondiging dat de software open source zou worden, was er nog niet. Het gerucht deed al wel de ronde dat PowerShell de volgende software van Microsoft zou zijn die open source zou worden. Eind juli tweette een PowerShell-tester al dat hij verwijzingen naar het open source maken had gevonden in de metadata van de deb-package van de tool.

Microsoft bracht PowerShell voor het eerst uit in 2006 en de versie van de software die nu is uitgebracht is alfa 6.0. De nieuwste releaseversie van Powershell is momenteel nog 5.1. PowerShell kan gezien worden als 'opvolger' van de MS DOS commandline-interface. De eerste versie was geschikt voor Windows XP SP2, Server 2003 en Vista. Het is een objectgeörienteerde shell- en scripttaal gebaseerd op het .net-framework. De tool wordt veel gebruikt door administrators om taken uit te voeren binnen COM en WMI. Eerder dit jaar werd ook bekendgemaakt dat het omgekeerde gebeurd was: Unix-shell Bash was onderdeel gemaakt van Windows.

Reacties (143)

[Anoniem: 371241]

Voor die mensen die geen idee hebben wat PowerShell toevoegt, is hier een video met een uitleg en een paar demos:

https://azure.microsoft.c...nd-is-available-on-linux/

Demos:

• 12:30 Azure (MS's cloud platform, niet interessant voor Linux gebruikers)
• 15:58 Python, Rest & JSON (GitHub API)
• 27:54 Containers (docker)
• 34:39 hoe PowerShell bijvoorbeeld crontab eenvoudiger maakt
• 42:28 PowerShell Linux & Amazon Web Services (S3)
• 45:55 VM Ware

[Reactie gewijzigd door Anoniem: 371241 op 26 juli 2024 04:30]

[Jerie]

12:30 Azure (MS's cloud platform, niet interessant voor Linux gebruikers)

Je kunt ook Linux draaien op Azure.

[arjankoole]

Als je je scripts goed schrijft, wordt het geen complexe janboel.

Het valt of staat bij hoe vaardig degene is die de code schrijft. (ok, en hoe geschikt de taal in kwestie is voor het kunnen structureren van de code, en toegegeven : python dwingt dat fijn af.)

[sfranken]

Ook dat ligt aan de programmeur. Ik neem aan dat je zelf niet programmeert?

[GeeMoney]

Ik voorzie een beperkte meerwaarde hoor.
Linux en macOS hebben natuurlijk gewoon o.a. de bash shell beschikbaar, waarom zouden die nu opeens Powershell gaan gebruiken?

[Reactie gewijzigd door GeeMoney op 26 juli 2024 04:30]

[84hannes]

Er zijn heel veel shells voor Linux en ik denk niet dat Bash de beste is. Ik heb een uurtje fish gebruikt, en vond deze meteen prettig werken, maar ben weer teruggeswitched toen ik een script wilde runnen. Uiteindelijk is Bash gebruiken net als Windows gebruiken: iedereen gebruikt het, dus het wordt ondersteund, maar het is technisch niet de beste keus. Zelf ben ik wel gecharmeerd van het objectgeorienteerde karakter van PowerShell: in Bash is alles een tekst, in PowerShell is alles een object. Als je in Linux het grootste bestand op je harde schij wilt traceren moet je bij wijze van spreken:

• Alle bestanden en hun grootte in bytes weergeven
• De output sorteren op kolom n (de kolom waar de bestandsgrootte in staat)
• De eerste regel weergeven
• De kolom waar het pad en de bestandsnaam in staan selecteren
• Dit bewuste bestand en zijn grootte in human readable formaat (GB) weergeven

Dus zoeits als (ik ken de exacte syntax niet)
ls -recursively | sort -n | head -n=1 | ls -h
Als je een klein beetje programeerervaring hebt werkt PowerShell veel intuitiever:

• Je maakt een lijst van alles bestanden.
• Je sorteert deze lijst op het .size element
• Je geeft het eerste resultaat weer

Dus zoiets als (ook deze syntax ken ik niet)
ls().sort(size)[0];
(overigens vind ik de naam van commando's in powershell ook veel voorspelbaarder dan de serieus grappige maar cryptische namen in Linux/Bash)
Ik weet dat mensen die al tientallen jaren Linux gebruiken heel goed zijn in text parsen, maar persoonlijk ben ik er nooit echt comfortabel mee, terwijl object georienteer programmeren mij veel bekender is.

edit:
Ik ben teleurgesteld in de echte syntax. PowerShell:
gci . -r | sort Length -desc | select fullname -f 1
Bash:
find . -printf '%s %p\n'|sort -nr|head -n1

[Reactie gewijzigd door 84hannes op 26 juli 2024 04:30]

[MneoreJ]

Het PowerShell commando is "dir -recurse | sort -prop length -desc | select -first 1". Er gaan obejcten door de pipeline, maar het blijft wel een pipeline. In Unix is de pipeline puur tekst, wat sommige dingen inderdaad moeilijker maakt (maar het ook makkelijker maakt universele tools te schrijven, aangezien alles met tekst kan werken).

Voor de moeilijker dingen zou je in Unix eerder samengestelde tooltjes krijgen: find om bestanden makkelijker te vinden, awk voor gestructureerdere tekstprocessing. In PowerShell hoef je veel minder naar extra tooltjes te grijpen omdat het feitelijk een complete programmeertaal is, met als bonus toegang tot alle classes in .NET.

[Zarhrezz]

Voordeel van het objectgeoriënteerd zijn is ook dat je makkelijk xml maar bv. ook met SQL kan werken. De xml die je van een DMX query op een OLAP cube krijgt kun je direct met XPATH door als je dat zou willen.

En inderdaad, gebaseerd op .net dus .net reflection is ook direct te gebruiken.

Ook even alle tekstbestanden in een directory structuur doorzoeken op een keyword ('error' of 'exception', om maar wat te noemen) en de betreffende regels uit de betreffende files al dan niet met file name + path en regelnummer op het scherm zetten is maar een enkele regeltje.

[ro8in]

Dat kan op linux ook heel makkelijk met het tooltje grep. Wat zowat bij elke distro wel standaard ingebouwd zit.
Zoals poster hierboven zegt, bevat bash ondertussen jaren en jaren aan ontwikkelde tooltjes om dingen handiger te maken.
Het blijft natuurlijk een cool idee dat je shell object georienteerd is, maar tegelijkertijd is het bijna een beetje overbodig op linux/unix. Zowat alles wat je op de shell zou willen kunnen, kan ondertussen wel al.
Voor windows is het natuurlijk een hele verbetering.

Voorbeeldje van een bash command met een tooltje find: find . -type d -size +100M

[Reactie gewijzigd door ro8in op 26 juli 2024 04:30]

[Zarhrezz]

Ik heb nauwelijks Linux ervaring dus het vergelijk kan ik niet maken, maar voor m'n werk heb ik nu een kleine 20 scripts in m'n share op werk staan voor utility scripts bij m'n werk. Als ik remote ingebeld zit op een server kan ik die even kopiëren en uitvoeren zonder hiervoor iets te installeren / configureren. Goed werkbaar dus.

Hierbij heb ik te maken met een product wat op SQL draait (aantal DBs op een Standard instance, incl. OLAP cube, andere op Express instance). PowerShell is daarbij erg handig omdat je direct SQL / MDX kan uitvoeren, geen gepruts met extra tooling.

Ook is het erg krachtig voor geautomatiseerd testen; met een enkel PowerShell scrip kun je een install van je product doorlopen, databases vullen, services herstarten (bij ons nodig om datasynchronisatie te doen), extern testtool draaien om data aan de services te voeren, vervolgens de voortgang van de verwerking daarvan volgen door een (Delphi) .dll via reflection te benaderen en als dat klaar is een ETL starten en monitoren. Als die klaar is een extern testtool een test uit laten voeren en als dat klaar is (aan de hand van de exit-code) rapporten wat de uitkomst van de test is. Netjes even afsluiten door het .htm rapport even in een browser te openen. Veel krachtiger dus dan een simpel batch-vervangertje dat sommige mensen denken dat het is.

[halofreak1990]

Volgens mij zijn grep en find geen tools van bash zelf, maar losstaande programma's. Bash zelf is alleen een command interpreter.

[ro8in]

Dat klopt het zijn losse programmas, maar zo ongeveer wel standaard op alle unix systemen.

[R4gnax]

Het PowerShell commando is "dir -recurse | sort -prop length -desc | select -first 1". Er gaan obejcten door de pipeline, maar het blijft wel een pipeline. In Unix is de pipeline puur tekst, wat sommige dingen inderdaad moeilijker maakt (maar het ook makkelijker maakt universele tools te schrijven, aangezien alles met tekst kan werken).

Powershell werkt met een mate van dynamic typing, type inference en type conversions waardoor cmdlets niet zo limiterend zijn met hun argumenten als je op het eerste gezicht zou denken.

[Reactie gewijzigd door R4gnax op 26 juli 2024 04:30]

[Hellboy!]

Gebruik dan Python.

[MneoreJ]

Hoe ziet het commando "geef me het grootste bestand op de schijf" in Python er dan uit? Welke modules moet ik daarvoor eerst importeren? Heeft Python een pipeline?

Ik ben toegegeven geen begaafd pythonist, maar ik heb er meer dan 10 seconden voor nodig om dat op te hoesten. PowerShell blijft toch eerst en vooral een shell, net zoals Python eerst en vooral een scripttaal is. Het maakt voor het dagelijks gebruik natuurlijk wel behoorlijk uit welke insteek een taal heeft, ook als je er in theorie alles mee kunt.

(Ik ga natuurlijk sowieso voorbij aan het feit dat PowerShell standaard bij Windows zit en Python niet, aan zulke dingen is altijd wel een mouw te passen, net zoals ik Win32 ports van bash installeerde toen PowerShell nog niet bestond.)

[Reactie gewijzigd door MneoreJ op 26 juli 2024 04:30]

[computergek80]

Ja, jeh hebt helemaal gelijk over de insteek.

En grappig dat je nu noemt dat Python niet standaard in Windows zit. PowerShell zit dan weer niet standaar in bijvoorbeeld macOS, maar Python weer wel.

[japborst]

En om het makkelijk te maken zit Bash met 1 klik in Win10, inclusief Python 2 en 3 🙌

[Miks]

1 klik?

[japborst]

Vinkje zetten, reboot en wachten op een installer:
http://www.howtogeek.com/...bash-shell-on-windows-10/

[Miks]

Heeft het dan ook Python?

[japborst]

Ja, zowel python 2.7.6 als python 3.4.3 word standaard meegeleverd. Verder kan je ook gewoon apt-get gebruiken.

[computergek80]

Dat is natuurlijk een overdrijving, maar je kunt tegenwoordig van Microsoft een of ander pakket installeren dat gewoon een volledige Linux installatie is met werkende koppelingen aan het filesystem en de kernel.

[Jerie]

Hoe ziet het commando "geef me het grootste bestand op de schijf" in Python er dan uit? Welke modules moet ik daarvoor eerst importeren? Heeft Python een pipeline?

OP heeft al het UNIX commando gegeven. Dat maakt het heel simpel om het in Python uit te voeren met de os module. Het is een soort van lazy way out waarmee je je kennis van UNIX (die je in dit geval wordt aangereikt) in Python kunt gebruiken. En je behoort het als Python beginner te weten. Verder is de documentatie van Python uitstekend.

Maar jij bent een PowerShell gebruiker en je post geeft heel mooi weer waarom het handig is dat dit geport wordt naar *NIX (Linux en macOS). Er zijn meerdere wegen die naar Rome leiden, en het gaat er om welke voor jou (of jouw organisatie) het fijnste werkt. Snelheid (tijdverlies) kan daar een belangrijke rol bij spelen.

[Reactie gewijzigd door Jerie op 26 juli 2024 04:30]

[MneoreJ]

OP heeft al het UNIX commando gegeven. Dat maakt het heel simpel om het in Python uit te voeren met de os module.

En dat commando werkt dan niet voor Python op Windows, dus dat is echt valsspelen. Ik bedoel natuurlijk dat het moeilijker/minder snel is om dit in native Python te doen.

Natuurlijk moet je doen wat werkt, dat is altijd zo als je gaat scripten; mijn post was een reactie op "waarom gebruik je niet gewoon Python". Welnu, omdat Python geen shell is dus. Dat elke hogere programmeertaal wel een of andere escape naar het OS heeft is een beetje een dooddoener.

[Reactie gewijzigd door MneoreJ op 26 juli 2024 04:30]

[Jerie]

Wat werkt niet op Python voor Windows? Heeft dat de os module niet? Je kunt namelijk wel gewoon find.exe gebruiken van bijvoorbeeld Cygwin.

Ik weet niet hoe makkelijk het is om die find syntax naar native naar Python te porten. Heb me er niet in verdiept.

[GeeMoney]

Ik noem bash niet omdat het beter is, maar omdat het algemeen als de default gebruikt word bij de populaire distro's.
Ik zit zelf op ksh maar dat komt door AIX .
Ze hebben elk hun eigen voor en nadelen, zo zijn extended regular expressions een groot voordeel van bash. Punt is wel dat 90% van je code zonder veel moeite op veel shells zal werken. Powershell natuurlijk niet onder (bijvoorbeeld) bash. Wel grappig hoe de MS kant zo aan het wijzigen is eigenlijk, eerst was de GUI heilig en nu slopen ze er steeds meer functies uit.

[MneoreJ]

De GUI is nog steeds heilig in de zin dat je bijna alles ook gewoon in de GUI kan en veel Windows beheerders toch nog steeds liever een wizard voorgeschoteld krijgen. Die eenvoud is een van de grote selling points van Windows. Alleen heeft nu ook Microsoft het licht gezien wat betreft automatisering en herhaalbaarheid en virtualisatie, waar je juist liever geen GUI bij gebruikt. Je kunt, in recente versies van Windows Server, de hele grafische shell eruit laten slopen en alleen nog maar een commandopromptje achterlaten (en straks kun je zelfs Server Nano installeren, dat nog dichter bij een standaard X-loze Linux zit) maar verplicht is dat allemaal niet. Ik kan zo snel geen dingen bedenken die juist alleen met PowerShell te doen zijn en niet via een of andere grafische beheertool.

[Killah_Priest]

Een groot deel van Exchange is NIET in te stellen zonder Powershell, de opties zitten gewoon niet in EMC of ECP. En zo ken ik letterlijk honderden andere (Windows) dingen welke niet via de GUI te managen zijn maar wel via Powershell (ik doe als Windows admin tegenwoordig 90% van mijn werk in Powershell. Het is vaak sneller en stukken efficiënter als met de GUI werken)

[Glashelder]

En helaas ook een stuk gevoeliger voor fouten.

Om bijvoorbeeld de property -GrantSendOnBehalf te nemen van Set-Mailbox. (Exchange). Dat commando overschrijft vrolijk alle eerder ingestelde rechten. Om een account toe te voegen moet je weer terugvallen op een obscure syntax:

@{Add=”<value1>”, “<value2>”, “<value3>”}

In een GUI overkomt het je niet zo snel dat je rechten per ongeluk intrekt. In Powershell daarentegen. Oke, als je het eenmaal weet is het geen probleem meer, maar toch..

[Reactie gewijzigd door Glashelder op 26 juli 2024 04:30]

[Gyzome]

Om maar een persoonlijk voorbeeld te geven: de gebruikte encryptie-algoritmen voor een VPN-verbinding aanpassen lukt alleen via powershell.

[Mijzelf]

Ik heb nooit powershell gebruikt, maar in jouw voorbeeld lijkt mij het grote probleem dat powershell zèlf ondersteuning moet hebben voor -in dit geval- listen van alle bestanden.

Bash (en andere bash-achtige shells) hoeven dat niet. Je roept gewoon een of andere externe tool aan waarvan de (tekst) output je geeft wat je nodig hebt, die je weer door andere externe tools gooit om de ongewenste zooi weg te filteren.

In het geval van listen van alle files is dat niet zo'n issue natuurlijk, maar het lijkt me dat powershell afhaakt bij de meer obscuurdere taken, òf dat powershell een monsterlijk groot programma is (of de .NET backend).

[MneoreJ]

Je kunt PowerShell misschien beter zien als een soort bash en perl ineen. Als je op Unix een specifieke tool niet hebt grijp je waarschijnlijk ook niet gelijk naar de C compiler om iets te maken waar bash dan weer op voort kan borduren, maar meer kunnen dan de shell builtins plus het minimum aan standaardtools komt wel vaker voor.

Die monsterlijke grootte valt volgens mij wel mee, al moet ik zeggen dat je dat op een standaard Windows installatie van ettelijke GB toch niet merkt

Overigens is het voorbeeld dat je aanhaalt (het moet bestanden op kunnen hoesten) juist wel een aardige illustratie van waar PowerShell net wel modulair is: Get-ChildItem is een algemeen commando, het zijn zogenaamde providers die die commando's implementeren en die zijn pluggable. Het bestandssysteem is één provider, maar de registry is bijvoorbeeld een andere. "dir HKLM:\\" werkt ook gewoon om de subkeys van HKEY_LOCAL_MACHINE op te hoesten. Nu is een provider schrijven niet iets wat je eventjes uit verveling doet, maar toch.

[Reactie gewijzigd door MneoreJ op 26 juli 2024 04:30]

[SirBlade]

Daar heeft powershell modules voor, zowel van MS als van 3rd parties. Bekende voorbeelden zijn de ActiveDirectory module of de VMware module. Binnen die modules vind je onder andere commando's. Die commando's zorgen voor de output naar powershell, zonder dat je daar ongewenste zooi voor hoeft op te ruimen.

Met de bovenstaande modules zou ik bv 2 lijsten met objecten kunnen maken, 1 met alle servers in mijn AD, de andere met alle VM's in ESX V. Vervolgens kan ik die 2 lijsten met elkaar vergelijken en een derde lijst maken van alle servers in de AD die niet in ESX voorkomen. Beide modules hoeven niets van elkaar te weten, ze hoeven alleen maar met powershell te kunnen praten.

[tweazer]

In dit find commando zie ik geen restrictie op file versus directory. Technisch is een directory entry vergelijkbaar met een file alleen ...

Sneller, maar wel langer als commando is:
[root@tmp]# time time find / -type f -ls 2>/dev/null | awk '( $7 >= tel ) { tel = $7; naam = $11 } END{ print tel " " naam }'
140737486266368 /proc/kcore

real 0m4.934s
user 0m2.422s
sys 0m2.572s

ten opzichte van (met de restrictie type f):
[root@tmp]# time find / -type f -printf '%s %p\n' 2>/dev/null |sort -nr|head -n1
140737486266368 /proc/kcore

real 0m5.976s
user 0m4.583s
sys 0m1.410s

[ZpAz]

Gebruik hier Fish ook, maar als je script begint met de shebang syntax voor bash moet dat natuurlijk gewoon onder bash gaan draaien.

[Anoniem: 145867]

Heel veel shells zijn echt geweldig op Linux. Maar je weet dat op elke bak en server bash vaak draait. Dus hou je het vaak gewoon bij bash. Niet omdat er betere alternatieven zijn, maar omdat dat de standaard is.

[Jerie]

Er zijn heel veel shells voor Linux en ik denk niet dat Bash de beste is. Ik heb een uurtje fish gebruikt, en vond deze meteen prettig werken, maar ben weer teruggeswitched toen ik een script wilde runnen

Het is dan de vraag of standaard Fish gebruiken en alleen Bash gebruiken als het moet. Je kunt in een script gewoon een shebang maken. Wil je een script interactief in een shell draaien dan kun je Bash vanuit Fish starten. Wil je Fish slechts proberen kun je Fish vanuit Bash starten. Ik zelf vind Fish na een korte learning curve veel prettiger werken dan Bash maar idd de backwards compatibility. Echter gooi ik Bash niet van een systeem af. Het is nog steeds te gebruiken. Bestaande scripts werken nog steeds.

[wildhagen]

Omdat je nu vanaf één beheerserver ook direct je Windows-machines kan beheren (alle Windows-beheer kan immers via Powershell gebeuren)?

Scheelt je weer een aparte management-server per OS, en dus licentie, onderhoud etc op die server

[GeeMoney]

Alle andere zaken kan je nog steeds niet? Eigenlijk voor alles heb je nog de tools/omgevingen van MS nodig. (Sscm,wsus etc.) die fungeren dan toch vaak ook als management server?
Ook zijn de platformen vaak door eigen disciplines in beheer. Misschien de kleine toko's die dit dan samen kunnen voegen maar ik zie een ING niet opeens alles omgooien.

[wildhagen]

Ik zeg ook niet dat het meteen al je Window-servers overbodig maakt, want dat doet het uiteraard niet, en ik verwacht ook niet dat dat ooit zal gebeuren. Het is geen wondermiddel ofzo.

Het maakt cross-platform beheer alleen wel weer een stukje makkelijker allemaal.

Overigens kan je zowel SCCM als WSUS (stand-alone of als onderdeel van SCCM) gewoon via Powershell beheren, de GUI ervan heb je in principe niet of nauwelijks meer nodig.

[Reactie gewijzigd door wildhagen op 26 juli 2024 04:30]

[bbc]

Ik heb zelf wat zitten scripten op het werk in een LAMP omgeving. Het doel was om allerlei gegevens te combineren, AD, LDAP, inventaris DB, locatie DB, monitoren van het netwerk en wat snmp dingen checken.

PC informatie dumpte ik echter in logs die ik parste. Lijkt me wel leuk om de dingen nu met powershell te gaan ophalen, of misschien met powershell vanaf de windows bak te pushen.

[BoringDay]

Op het moment dat ik iets met powershell probeer te doen dan begin ik meteen de bash weer veel meer te waarderen wat een gemis is dat dan.

[MneoreJ]

Ik heb met beide gewerkt en ik kan je verzekeren dat dat echt puur een kwestie van gewennen en leren is. In beide omgevingen kun je alles wat je wil, alleen is de insteek anders. Op Windows kom je alleen wel aantoonbaar verder met PowerShell omdat Microsoft erop let dat alles in Windows te doen en in te stellen is via cmdlets die standaard naamgeving en interface hanteren (zoals alle config op Unix beschikbaar moet zijn via tekstbestandjes en/of dedicated tooltjes, maar dat is een stuk minder uniform).

[Rinzwind]

Powershell is traag. En remoting al helemaal (office 365). Daarbij heeft ps voor nota bene .net programmeurs heel eigenwijze kuren/keuzes en mistte het lang vanzelfsprekende beheertaken zoals AD. Het bewerken/zoeken in AD gaat dan weer veel sneller via het aloude VBScript... .net werkt niet zo vlotjes samen met com.

[MneoreJ]

Het is niet perfect, nee. Maar die andere methodes zijn ook niet plotseling uit Windows gesloopt; je kunt die nog steeds gebruiken waar nodig/handig (WMI is er ook zo een). De vergelijking hier was met bash, en dan is PowerShell onder Windows toch wel een stuk universeler.

[Killah_Priest]

Ik heb nog nooit echt traagheid ervaren met Powershell. En met het remoten ook niet (on-premises en servers op een colo). 365 staat er sowieso om bekend dat het soms traag aan kan voelen, dat heeft weinig met Powershell te maken. En versie 1 had al gewoon de mogelijkheid om AD te managen hoor, je moest echter direct .NET aanspreken daarvoor (System.DirectoryServices). Vanaf versie 2.0 zijn er ook AD CMDlets beschikbaar vanuit Microsoft, maar voor die tijd kon je dus al gewoon AD managen.

[Anoniem: 120539]

Ik heb nog nooit echt traagheid ervaren met Powershell.

Dan heb je kennelijk nog niet veel bulk-processen gedraaid en/of vergeleken met functioneel gelijke scripts in .vbs; Powershell is dan toch echt een stuk langzamer.
De vraag is meer hoe relevant het is; een script dat je telkens handmatig start en waar je op zit te wachten kan lastig zijn, maar voor een gescheduled script dat elke 5 min draait is het voor mij niet heel relevant of dit na 30 of 44 seconden klaar is.

Los daarvan is Powershell natuurlijk niet beperkt tot scripting; juist de krachtige oneliners zijn een belangrijk sterk punt.

[Killah_Priest]

Ik draai wel degelijk bulk processen : de truc tegen traagheid (niet altijd toepasbaar) is je scripts bv parallel te laten processen (zij het via start-job, workflows of runspaces).
verschil tussen bv 300 machines in bulk uitlezen via WMI : sequentieel 30 minuten. Parallel : 30 seconden.

Volgens mij is VBScript ook gebouwd rond het gebruik van COM objecten, Powershell is gebouwd rond .NET objecten (ik heb nooit echt veel gescript in VBS dus helemaal zeker weten doe ik het ook niet)

Nou moet ik wel eerlijk zeggen : ik gebruik steeds minder vaak ingebouwde CMDlets en bouw steeds vaker mijn eigen implementaties adv de beschikbare .NET classes, ook omdat er nog wel eens rare bugjes zitten in bepaalde CMDlets (Invoke-WebRequest bv : als de response de encoding in quotes heeft staan (dus bv "UTF8" ipv UTF8) dan krijg je een exception. Idem bij Invoke-RestMethod. Gevolg is dus dat ik weer een eigen implementatie moet maken adv System.Net.HttpWebRequest

[Reactie gewijzigd door Killah_Priest op 26 juli 2024 04:30]

[mrdemc]

Dat kan ik beamen. Ik gebruik powershell heel veel voor het serverbeheer in de azure omgeving (scalen en automatische setup van servers) maar ook daarbinnen voor bepaalde installatie en bijwerk acties. Vervolgens gebruik ik het ook graag voor mijn workstation maar bash vind ik weer lekker werken onder Linux. Ze hebben beide hun krachten en zijn beide fijn, als je de tool maar begrijpt die je gebruikt ik kan ook alleen maar blij zijn hiermee, scripts zijn naar mijn idee heel gemakkelijk te schrijven. En dat icm een job die gelijktijdig acties uitvoert op alle servers en ja dat kan ook met bijv. Bash, maar zo ieder zn voorkeur

[Reactie gewijzigd door mrdemc op 26 juli 2024 04:30]

[BoringDay]

Ja zo blijven we maar doorgaan met gewennen. Ik wil niet meer gewennen aan afwijkende methodes terwijl hier al lang standaarden en afspraken voor zijn.

[ro8in]

Ik ben het met je eens.

Powershell zal best oke zijn en waarschijnlijk gewoon een kwestie van alle commandos leren en herinneren.

Echter merk ik dat met mijn 35 jaar en 20 jaar bash gebruik ik er niet meer zo snel in kom als dat ik deed toen ik 15 was. Het levert mij tot nu toe alleen frustratie op, wat geloof ik niet het doel van powershell hoort te zijn. Zolang ik het niet echt nodig heb blijf ik er dan ook liever van weg.

Denk dat in dit geval powershell goed vs slecht een gevalletje leeftijd generatie is. Jongeren typen er in noodtime in weg, terwijl wij ouderen er maar wat warig in zullen stuntellen haha.

[Reactie gewijzigd door ro8in op 26 juli 2024 04:30]

[Anoniem: 420148]

Omdat je met PowerShell Windows-servers kunt beheren/manipuleren. Het hoeft dus geen plaatsvervanger voor Bash te zijn om je OS zelf te beheren.

[Anoniem: 145867]

Vanuit Linux je "windows" servers beheren? Komt zo'n combinatie ergens voor? lol

[Anoniem: 420148]

Een hostingbedrijf, of een bedrijf waar de werknemers wellicht op Windows desktops icm AD/DFS werken en veel applicaties op Linux runnen. Er zijn zat bedrijven waar allebei draait en zat beheerders die liever Linux runnen en niet elke keer een Windows VM willen aanschoppen om een server te beheren.

[Anoniem: 145867]

Oke, in ieder geval is het nu mogelijk. Dat is veel beter als niks. Dus voor diegene die dit wil is er nu een oplossing.

[StefanJanssen]

Ook beperkte meerwaarde is meerwaarde. Open source is altijd leuk:)

[goarilla]

Om te remoten met Windows Servers zonder Windows VM's te moeten gebruiken.

[Anoniem: 636203]

Ikzelf zie liever Python als scripting taal op Linux in plaats van Bash.

[kwakzalver]

Zoveel mensen zoveel smaken.

Ben je gewend aan bash shell kan je dit nu in Windows gebruiken.
Ben je gewend aan Power Shell kan je dit nu in Linux/osX gebruiken.

Uiteindelijk moet eenieder kiezen wat het beste bij ze past en daarmee aan de slag gaan.

De discussie welke beter is of beter werkt zal er altijd zijn. Uiteindelijk na jaren alles gezien te hebben is het eigenlijk 1 pot nat. Allemaal functioneel waarvoor het ontworpen is en dat is de belangrijkste constraint.

Wat Microsoft wel doet is het verlagen van de drempel om cross platform iets te ontwikkelen.
Een stap die ze al ruim een tijd hebben gedaan door bijvoorbeeld de Apple Apps functioneel te maken in Windows Windows Phone.

[halloallemaal]

Microsoft bracht PowerShell voor het eerst uit in 2006 en zit tegenwoordig op versie 6.0.

Versie 5.0 toch of heb ik iets gemist?

[MrDayOff]

Volgens mij heb je daar helemaal gelijk in, in de anniversary update van Windows 10 zit versie 5.1. Echter is de open source variant op versie 6.0

Downloads:

Ubuntu 14.04
https://github.com/PowerS...ubuntu1.14.04.1_amd64.deb

Ubuntu 16.04
https://github.com/PowerS...ubuntu1.16.04.1_amd64.deb

CentOS 7.1
https://github.com/PowerS...9-1.el7.centos.x86_64.rpm

Mac OS X 10.11
https://github.com/PowerS...ershell-6.0.0-alpha.9.pkg

[wildhagen]

De meest recente Windows Powershell-versie is versie 5.1, die meegeleverd wordt met de Anniversary Update van Windows 10, die op 2 augustus uitkwam

PS C:\> $PSVersionTable

Name Value
---- -----
PSVersion 5.1.14393.0
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.0
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

[Reactie gewijzigd door wildhagen op 26 juli 2024 04:30]

[PhoenixT]

.net is geen programmeertaal, beste auteur Ook is het .NET in hoofdletters!

[Reactie gewijzigd door PhoenixT op 26 juli 2024 04:30]

[capsoft]

Mark did not C#
Waarschijnlijk een Java dev ;-) https://twitter.com/msdev/status/393044144702373888

[Reactie gewijzigd door capsoft op 26 juli 2024 04:30]

[Proxx]

[TWyk]

Vereist Powershell ook niet de installatie van .NET om alle commandlets te kunnen gebruiken?
Dat is toch niet beschikbaar op Linux?!

[wildhagen]

Het .NET Framework (iig de Core) is al een tijdje geleden naar Linux gebracht, zie bijvoorbeeld dit nieuwsartikel uit 2014: nieuws: Microsoft brengt .Net naar Linux en OS X en maakt .Net Server Core op...

[atlaste]

Op zich klopt dat, maarrrr .NET framework != .NET core. .NET core is echt anders dan .NET framework... Zo anders dan Microsoft nog steeds aanraadt om Mono te gebruiken als je wat meer wilt dan alleen de basis. Hoe enorm die verschillen zijn merk je pas als je een ASP.NET MVC applicatie probeert te porten naar ASP.NET Core.

Powershell onder windows gebruikt volgens mij .NET framework 4.5. Powershell onder linux gebruikt .NET core.

[Pietervs]

Als de vos de passie preekt, boer pas op je kippen...

Microsoft heeft in het verleden al eerder gedaan alsof ze de Linux-community accepteerde, om vrij snel daarna te dreigen met allerlei rechtszaken vanwege patent-inbreuken.

Het feit dat Bash nu beschikbaar is in Windows, en omgekeerd .net en Power Shell even ondersteund gaan worden op Linux en Mac is leuk, maar ik wil zien hoe lang dit stand houdt.

tegelijkertijd: MS moet iets doen want Win10 op de telefoons slaat niet echt aan. Doormhet cross-programmeren makkelijker te maken zal MS hopen wat devvers over de streep te trekken om ook voor Win10 te gaan ontwikkelen

[MneoreJ]

De tijd dat Microsoft de grote boeman was die Linux het liefst van de aardbodem wilde vagen doormiddel van FUD en patentzaken ligt echt alweer jaren achter ons (en die strijd hebben ze glansrijk verloren). Ze marcheren nu juist oprecht toe naar alles open source maken, en dan écht open source, niet via zo'n neplicentie waarbij je de source wel mag zien maar er niks mee mag doen. Ja, het is even wennen, maar ze doen dit keer gewoon gezellig mee. En waarom ook niet? Ook MS ziet in dat je daar gewoon geld mee kunt verdienen, en meer nog dan wanneer je alles op je eigen proprietary platformpje houdt. Meer mensen die Windows kunnen/willen beheren? Yes please, dat maakt Windows zelf ook weer waardevoller. Meer mogelijkheden om Linux te integreren in je Windows-opstellingen? Go ahead, economisch veel zinvoller dan dat MS al die software zelf opnieuw zou moeten gaan maken. Met pure vendor lock-in alleen ga je het niet redden in de toekomst van virtualisatie en cloud computing. Ook MS wil meer toe naar diensten verkopen en minder naar software verkopen.

Het is/was misschien een cultuurschok, maar ook bij MS is open source nu salonfähig. Hoe lang houdt dit stand? Nou, laten we het zo zeggen: je kunt nu daadwerkelijk, als je wil, .NET Core forken als MS het niet meer ziet zitten. Hoeveel toekomstbestendiger wil je het hebben? (Patentzaken zijn idd nog een mogelijkheid, maar zoals eerder al gedemonstreerd in andere projecten kan de community om zulke dingen heen schrijven als het moet. Daarnaast belooft Microsoft expliciet dat ze je niet zullen aanklagen over patenten, al heeft dat juridisch gezien natuurlijk weinig om het lijf.)

[Reactie gewijzigd door MneoreJ op 26 juli 2024 04:30]

[Cerberus_tm]

Waarom doet Microsoft dit eigenlijk? Op zich goed, maar wat is hun doel hiermee?

[inorde]

Microsoft investeert stevig in de cloud. Software als .NET en Powershell begonnen achter te lopen op (open source) alternatieven. De boel open source maken is en van de staken die ze nemen om hun software aantrekkelijker te maken voor andere platformen als Windows.

Azure biedt veel mogelijkheden om software en infrastructuur de hosten in de cloud. Hoe meer kennis er in de wereld is van .NET en Powershell, hoe eerder mensen voor Azure gaan.

Ik vind het een goed plan, want je merkte dat ze achter begonnen te lopen in en wereld die razendsnel veranderd.

[Cerberus_tm]

Okee, dus waar het om gaat is dat Microsoft Powershell gebruikt in programma's en/of diensten die het zelf verkoopt of gebruikt, en dat het hoopt dat andere mensen mee zullen helpen Powershell te verbeteren als de broncode openbaar wordt en het beschikbaar komt op Linux e.a.?

[bush]

denk niet dat dat de reden is. Azure werkt net zo goed met Linux. 30% van alle VM's in Azure zijn Linux. Sommige PaaS services draaien Linux. Azure is verre van .NET only

[inorde]

Als PowerShell en .NET beter bekend en gebruikt worden is het denk ik aantrekkelijker om naar Azure te gaan, omdat het goed ondersteund wordt. Je kunt met PowerShell namelijk makkelijk VM's maken en inrichten.

[wildhagen]

Powershell aan een breder publiek beschikbaar maken?

Je kan nu vanaf één omgeving (in dit geval LInux of Mac)) ook je Windows-servers beheren, vanuit Powershell kan je immers alles wat je vanaf de GUI ook kunt, en nog meer (PS kan ook dingen die in de GUI niet kunnen).

[satya]

Een gok waar enkele mensen om mij heen het mee eens zijn.

Microsoft gaat van software leverancier bewegen naar een hele grote diensten leverancier. Kijk naar de open source markt, daar geven ze hun spullen bijna gratis weg, en wordt goed geld verdiend aan support en trainingen. Ik denk dat microsoft dit voorbeeld op haar eigen manier volgt.

[Donvermicelli]

Leuk en aardig van Microsoft maar ik vraag mij af wie hier op zit te wachten? De enige reden waarom PowerShell ontwikkeld is was omdat het oorspronkelijke CMD van Windows zo abominabel slecht was dat ze niet anders konden.

Voor *nix systemen zijn er allang genoeg opties bovenop de al goed werkende bash en terminal implementaties.

EDIT: Ik ben erg benieuwd waarom dit bericht gezien wordt als offtopic of ongewenst? Het slaat direct terug op het artikel en stelt gewoon een kritische vraag over de zet van Microsoft.

[Reactie gewijzigd door Donvermicelli op 26 juli 2024 04:30]

[nst6ldr]

Heb je PowerShell wel eens gebruikt? Ik kreeg het op m'n werk voorgeschoteld. In eerste instantie was ik sceptisch, maar met mijn achtergrond als C# programmeur is dit al heel snel mijn favoriete commandline geworden. Ik doe tegenwoordig nog amper wat met de GUI.

[Donvermicelli]

Zeker heb ik PowerShell gebruikt, ik ontken ook niet dat het krachtig is op Windows. Daar ligt dan ook de crux, op Windows zijn een aantal zaken lang niet mogelijk geweest met de GUI en heel lastig geweest met het oude CMD. Daarvoor moest toen een oplossing komen wat uiteindelijk PowerShell geworden is. Heel mooi allemaal voor gebruikers van Windows systemen maar *nix systemen hadden deze functionaliteiten al lang met gebruik van onder andere bash en terminal.

Nu waren die ook niet perfect opzich maar er zijn in de loop van de jaren al wat varianten gemaakt die de gaten opgevuld hebben. Microsoft komt dus héél erg laat bij het feestje kijken op een al verzadigde markt. Vandaar dus ook mijn terechte vraag: Wat is hier de meerwaarde van? Ik kan me niet voorstellen dat een Linux Sysadmin ineens PowerShell gaat gebruiken nu.

[Donvermicelli]

Nou de meerwaarde is dat je nu vanuit Linux je Windows servers kunt beheren. Er zijn echt vet veel mensen die dat op deze manier doen. Er zal dus echt heeeel veel vraag naar zijn.

Not sure if sarcasm or?....

In ieder geval heb je wel een punt dat het makkelijker wordt om dat te doen, heb zelf die use-case alleen nog nooit voorbij zien komen. Meestal als bedrijven Windows servers draaien dan hebben ze op de developer en sysadmin systemen ook wel Windows draaien en niet Linux of macOS

[Anoniem: 145867]

Misschien dat het een voordeel heeft voor Azure.

[wildhagen]

Powershell is idd extraam krachtig. Het vereist even een beetje verdiepen erin, als je gewent bent aan VBS-srcripting etc, maar als je het principe eenmaal doorhebt is het vrij eenovudig en extreem krachtig.

De toekomst op WIndows ligt bij Powershell, er zijn nu al taken die niet eens meer mogelijk zijn in de GUI bijvoorbeeld, maar alleen via Powershell (denk bijv aan het aanmaken van een shared mailbox in Exchange 2010+, kan niet meer via de GUI).

[Reactie gewijzigd door wildhagen op 26 juli 2024 04:30]

[Luminai]

Grappig genoeg wel in Exchange 2013. Nja, als je de ECP neemt als GUI. De management console van 2013 bestaat alleen nog uit een queue viewer.

[redfoxert]

De ECP voert zowel voor EX2010 als EX2013 en EX2016 gewoon onder water PS scripts uit, met variabelen die in de GUI hebt ingevoerd. Het is dus eerder een GUI voor de Exchange Management Shell ipv een "volwaardige" GUI.

[mrdemc]

Was daarvoor met 2007 ook al in de EMC

[kristofv]

Denk dan vooral ook aan de Nanoserver die binnenkort uitkomt samen met Server 2016.. daar heb je nog bitter weinig keuze buiten het werken met remote powershell.

(En de nieuwe Azure management tools "GUI" is ook een optie i know .. maar lang niet iedereen heeft uberhaupt een Azure account, ook bedrijven niet.)

[Amanoo]

Kan iemand me uitleggen waarom je PowerShell op Linux zou willen? Is het niet eerder andersom, dat je Bash op WIndows wil (wat overigens ook al bestaat)?

[nst6ldr]

Omdat PowerShell object georiënteerd is. Je kan het niet vergelijken met bash.

[Reactie gewijzigd door nst6ldr op 26 juli 2024 04:30]

[R4gnax]

Omdat PowerShell object georiënteerd is. Je kan het niet vergelijken met bash.

^ Dit.

De insteek van Powershell voorkomt een heleboel sores met verkeerde string escaping die bijv. heel akelige security issues met bepaalde bash scripts kan veroorzaken.

[BoringDay]

String escaping is toch totaal geen probleem als je weet hoe het werkt?

[Proxx]

vuur maken met stenen ook niet maar dat weerhoud ons niet om een aansteker te gebruiken.

[BoringDay]

Ja zo kan ik ook wel 1000 dingen verzinnen alleen slaat het nergens op.

[R4gnax]

String escaping is toch totaal geen probleem als je weet hoe het werkt?

Raketwetenschap ook niet.

[MacWolf]

Mocht je op een object-georiënteerde scripts willen schrijven, dan zijn Ruby en Python ook werkbare opties. En redelijke kans dat één van deze al aanwezig is op een Unix-achtige omgeving ten opzichte van PowerShell. Voor de meer ingewikkelde doeleinden, wat mij betreft een stuk prettiger dan Bash scripts schrijven (wat ook het doel zou kunnen zijn voor een PowerShell script).

Bash of Zsh zijn voldoende bruikbaar in Unix-achtige omgeving voor de simpele dingen. Ik denk niet dat PowerShell voldoende voordelen biedt dat mensen op Unix platformen deze shell in grote mate gaan installeren.

[Reactie gewijzigd door MacWolf op 26 juli 2024 04:30]

[Proxx]

maar ik vermoed dat powershell wel voordelen gaan bieden voor mensen die windows machines willen managen vanaf unix omgevingen

[Rinzwind]

En daardoor gelijk complex en overengineered. Zelfs programmeurs worden er geirriteerd van.

[nst6ldr]

Hoe kom je daar bij? Ik was programmeur voordat ik op een functie kwam waar ik het nodig had, heb er totaal geen problemen mee. Beter nog, veel proof of concepts waarvoor ik anders een asdftesttest.csproj moest aanmaken kan ik nu gewoon in één keer uit typen in PowerShell.

[plukke]

Ik ben juist zeer te spreken over het OO model binnen powershell. Het is even wennen maar daarna zeer krachtig en goed en makkelijk toepasbaar en scheelt echt bizar veel issues met string parsing.

Ander groot voordeel is dat je vanuit een script omgeving function calls kan doen op elke willekeurige DLL die je vindt. Zo had ik laatst een DLL van een fabrikant nodig om een status check te doen van een device. Zonder powershell had ik hier een .exe voor mogen bakken...

[Anoniem: 145867]

Ik snap die object georiënteerde hype niet. Juist functioneel georiënteerd is op dit moment populair aan het worden. Juist omdat je daar veel voorkomende problemen niet meer hebt zoals veel concurrency problemen met object georiënteerde aanpak. Denk aan F#, en andere functionele talen waar steeds meer vraag naar is. Hoe denk je anders dat whatsapp zoveel connecties kan krijgen op een relatief kleine server? Door object georienteerd filosofie?

Omdat mensen gebrainwashed worden op school dat object georiënteerd de heilige graal is zeker. Hallo het is geen 1990-2000 meer...

[Reactie gewijzigd door Anoniem: 145867 op 26 juli 2024 04:30]

[Psycho_Mantis]

Zo kan je direct vanaf je Linux of OSX bak naar je Windows Servers verbinden. Ik als Sysadmin vind dat wel handig, zo hoef ik geen VM meer te starten om powershell te gebruiken.

[atomos]

Mijn eerste reactie was van wat doet Microsoft nu met haar backslash ? ten opzichte van Linux/Mac enz ?
Je kunt niet zomaar de opdrachten heen en weer kopiëren..

[SirBlade]

In powershell kan je zowel / als \ gebruiken voor paden. De output maakt gebruik van \ onder windows, maar dat aanpassen in de unix versies zou niet moeilijk mogen zijn.

[Anoniem: 149075]

En wat voor spaties dan ?

[MneoreJ]

PowerShell is wat meer object oriented, dus dat gaat met strings in quotes (enkel of dubbel). dir 'my path containing spaces'. (En voor je het vraagt, quotes escape je met dubbele quotes, of met `.) En in plaats van "dir" mag je ook "ls" schrijven, beiden zijn een alias voor Get-ChildItem. Om even aan te geven uit welke hoek de wind van PowerShell waait. Basically, hij probeert zo vriendelijk mogelijk te zijn voor mensen die gewend zijn aan shells, om het even of dat Windows of Unix is.

[Anoniem: 149075]

Oh ik dacht juist dat we van die quotes eindelijk af waren hier door. Bummer!

[MneoreJ]

Ik werd in de tijd dat ik bash onder Windows gebruikte anders ook niet vrolijk van de hele tijd "C:/Program\ Files/Nog\ Meer\ Dingen\ Met\ Spaties":... onder Linux is af en toe een spatie escapen wel redelijk, onder Windows (waar mensen een stuk scheutiger zijn met spaties) is het echt wel een stuk fijner om de boel gewoon te quoten.

Maar als je echt wil kun je wel degelijk zonder quotes werken -- het escape-karakter in PowerShell is de backtick `. "dir C:\Program` Files\Microsoft` Office" werkt gewoon. Maar tab completion zal er standaard weer een quoted string van maken.

[84hannes]

En in plaats van "dir" mag je ook "ls" schrijven, beiden zijn een alias voor Get-ChildItem

Of gci

[MneoreJ]

Jawel, maar "dir" snappen de Windows mensen, "ls" snappen de Unix mensen, "Get-ChildItem" snappen de mensen die net even bekend zijn met PowerShell en snappen hoe de cmdlets een naam krijgen... en "gci" is dan echt weer zo'n afkorting omdat het kan.

[mrdemc]

Zover ik me kan herinneren was dir geen directe koppeling met getchilditem. Er was iig een soortgelijke functie (dir-achtig) die geen object uitgaf zoals get-childitem wel doet.

Even opgezocht: https://technet.microsoft.com/en-us/library/ee176841.aspx
Het is inderdaad wel meer dan alleen een dir

[Reactie gewijzigd door mrdemc op 26 juli 2024 04:30]

[BoringDay]

ls powershell is geen ls bash, dat is een wereld van verschil. ls in powershell is alleen maar irritant en verwarrend.

[Ulx]

Of je maakt een nieuwe alias:
New-alias WRKLNK get-childitem

[BoringDay]

Maar de standaard is: A non-quoted backslash, \, is used as an escape character in Bash. En voor de url /
Als we daar van gaan afwijken vind ik het niet meer vriendelijk.

[Luminai]

Waarom zouden spaties een probleem zijn? Alle paden met een spatie er in moeten toch ook uit geqoute worden op linux?

[RlndVt]

Nee op linux kun je de spatie backslashen.

[Seyaku]

Op linux/unix kan je een \ voor een spatie zetten om die mee te nemen in het argument.

[Luminai]

Weer wat geleerd

[Anoniem: 149075]

Zo zie je maar