Heading

Zoals elke programmeertaal, ondersteunt PowerShell commentaar. In feite ondersteunt het twee stijlen van commentaar. Maar zoals u verderop in dit artikel zult zien, kan PowerShell commentaar op een paar interessante en onverwachte manieren gebruiken, die heel krachtig kunnen zijn.

Commentaar gebruiken

De meest voorkomende stijl van commentaar die u zult zien, is een regel voorafgegaan door een #-symbool. (Ik laat het aan jou over om te beslissen of je dat een hashtag, een pond symbool, of zelfs een goede oude octothorpe wilt noemen!)

Als voorbeeld zou je aan het begin van je programma een commentaarblok kunnen hebben met details over het programma:

Commentaren zoals deze kunnen overal in je code terechtkomen. Een alternatieve manier om dit te doen, zou echter meer zijn wat ik een C-taalstijl zou noemen of soms een blokcommentaar wordt genoemd:

Met deze stijl kunt u gemakkelijker regels met commentaar toevoegen zonder dat er een # voor elke regel staat. Je bent vrij om beide stijlen te gebruiken of zelfs beide. Onthoud wel het nut van dergelijke commentaarblokken als je over een jaar terugkomt om je eigen code te debuggen. Commentaar hoeft echter ook niet aan het begin van een regel te staan. Persoonlijk gebruik ik commentaarblokken zoals hierboven alleen aan het begin van een script of vlak voor een bijzonder gecompliceerd blok code. Ik gebruik veel vaker endline commentaar zoals:

Ik heb dit commentaar in een recent script opgenomen omdat de| Out-Nullniet iets was waarvan ik verwachtte dat het nodig zou zijn, en ik weet dat ik me over een jaar zou afvragen waarom ik het commentaar daar had staan als ik het commentaar daar niet meer had staan. Of erger nog, ik zou het verwijderen en me dan afvragen waarom ik een cancel-bericht kreeg dat maar bleef opduiken.

Merk op dat wanneer je een commentaar begint met een #, alles tot het einde van de regel wordt behandeld als een commentaar. Dit kan bijvoorbeeld handig zijn als je aan het testen bent en het einde van een commando wilt uitcommentariëren.

Hiermee kun je later het commentaar verwijderen en de –online versie van help krijgen, maar wat als je een commentaar in het midden wilt? PowerShell geeft je die mogelijkheid.

Merk op dat door een commentaar in blokstijl te gebruiken, u de mogelijkheid krijgt om een commentaar in het midden van uw opdracht te plaatsen en toch de items rechts ervan uit te voeren of te interpreteren. Tenslotte vraagt u zich misschien af, “wat als ik een # wil uitprinten of iets dergelijks wil doen?” Als u dat probeert

Je zult merken dat het niet uitschrijft wat je wilt. Je krijgt gewoon:

Dit is waar het graf-accent ` van pas komt.

Hiermee drukt u het bericht af dat u wilt.

Je kunt ook de hele string tussen aanhalingstekens zetten:

Dat zou werken, maar ik wilde een voorbeeld geven van hoe je aan de # qualifier kunt ontsnappen.

Als je, net als ik, vaak de PowerShell ISE gebruikt om scripts te schrijven, is er nog een laatste handige truc die ik wil delen, maar die ik alleen kan beschrijven en een paar screenshots voor kan geven, niet daadwerkelijk een script voor kan leveren. Het is een sneltoets die niet specifiek is voor commentaar, maar die handig is als je een stuk code wilt uitcommentariëren, bijvoorbeeld om te testen. Zet de cursor aan het begin van de regel en terwijl je Shift-Alt ingedrukt houdt, gebruik je de pijltjestoetsen om de cursor omhoog of omlaag te bewegen. U zult een dun lijntje (blauw op mijn scherm) zien verschijnen. Als u de regels hebt gemarkeerd die u van commentaar wilt voorzien, typt u gewoon een # en het verschijnt aan het begin van elke regel.

Dit is een voorbeeld van de code om commentaar te geven:

Als u rechts van de tekst op regel 40 klikt en een paar keer op Shift-Alt en het pijltje omhoog drukt, ziet u de blauwe lijn verschijnen:

Nadat u op # <space> hebt gedrukt, ziet u de tekens die aan de code zijn toegevoegd:

Aantekening: je kunt deze truc overal op de regel gebruiken (dus als je een heleboel commentaar aan het eind van een aantal regels wilt zetten, kun je deze truc gebruiken om eenvoudig de # voor je in te voegen) en is uiteraard niet specifiek voor commentaar, maar dat is wel een van de meest voor de hand liggende manieren om het te gebruiken. Je kunt dit ook doen met reguliere expressies. Markeer het blok code in kwestie:

Dan Ctrl-H om het dialoogvenster Zoeken en vervangen op te roepen. Zorg ervoor dat Zoeken in selectie en Reguliere uitdrukkingen zijn geselecteerd:

Het caret ^ wordt gebruikt om het begin van een regel te verankeren en natuurlijk de # (daar staat een spatie) voegt in principe een # en een spatie in aan het einde van de gemarkeerde regels. Als je een blok code niet markeert, werkt dit op je hele script.

En meer

Als dat alles was wat commentaar in PowerShell kon doen, zou dit een heel kort en saai artikel worden (en mijn redacteur zou haar hoofd schudden met de woorden: “Greg, ik heb meer dan 850 woorden nodig!”). Zoals zoveel dingen in PowerShell, hebben de makers functies toegevoegd die het krachtiger maken dan je zou verwachten.

Ik was onlangs bezig met de voorbereidingen voor een presentatie die ik zou geven bij de Hampton Roads SQL Server User Group. Tijdens deze presentatie voer ik een script uit in PowerShell dat SQL Server start en stopt. Om dit te doen, moet ik het als administrator uitvoeren. Natuurlijk was ik dat tijdens een oefening helemaal vergeten, en toen ik het als mezelf uitvoerde, kreeg ik een aantal lelijke fouten. Dit was geen showstopper, maar niet wat je wilt tijdens een demo. Dit zette me aan het denken over hoe ik ervoor kon zorgen dat dit niet zou gebeuren tijdens de echte lezing.

Mijn eerste gedachte was om een cmdlet te vinden dat zou controleren als wie ik was ingelogd en dan af te breken als ik niet de juiste gebruiker was. Een deel van het probleem met deze aanpak is natuurlijk dat wanneer je een programma (zoals PowerShell ISE) als administrator uitvoert, je wordt weergegeven als de gebruiker die is ingelogd. Dit zou moeilijker worden dan ik dacht.

Opnieuw heeft PowerShell me verrast. Het oplossen van dit probleem is triviaal. Om te zien hoe u het probleem kunt oplossen, opent u de PowerShell ISE als uzelf (d.w.z. selecteer NIET uitvoeren als beheerder en zorg ervoor dat uw gebruiker geen lokale beheerdersrechten heeft) en voer de volgende code in:

Sla dit op in een bestand met de naam restart timer service example.ps1 en probeer het dan uit te voeren. Tenzij u een lokale beheerder op uw computer bent, zou u een foutscherm moeten krijgen zoals hieronder.

Als u dit uitvoert met de optie Uitvoeren als beheerder, zou het zonder fouten moeten worden uitgevoerd. In dit voorbeeld is de fout redelijk onschuldig, maar misschien schrijft u een script waarbij een fout niet zo onschuldig zou zijn. Om dit probleem op te lossen, zet je gewoon het volgende commentaar boven aan het script hierboven en sla je het opnieuw op.

Nu krijgt u een andere foutmelding:

Het is nog steeds een beetje lelijk, maar veel beter dan het script uitvoeren en misschien iets kapotmaken. Als je het script knipt en plakt in een nieuw venster, maar niet opslaat, zal PowerShell proberen het hele script uit te voeren. In principe wordt de #requires genegeerd, tenzij het een echt opgeslagen bestand is. Dit loste mijn eerste probleem op, maar het zette me aan het kijken naar andere functies waar ik me niet bewust van was. Voor #requires, is er een hele lijst:

Zoals u kunt zien, kunt u hiermee veel regelen over hoe en wanneer uw script wordt uitgevoerd. De #Requires –Version is handig als uw script functies vereist die alleen beschikbaar zijn in een recentere versie van PowerShell. Merk op dat dit een minimum aantal is. De versie van PowerShell die u gebruikt, moet hieraan voldoen of hoger zijn. U kunt dit niet gebruiken om een eerdere versie van PowerShell te vereisen. Een handig cmdlet dat ik bijvoorbeeld in een recent script heb gebruikt is compress-archive. Gelukkig was dit script specifiek voor het probleem dat ik probeerde op te lossen, maar als ik een meer algemeen script zou willen schrijven, zou ik misschien #requires –Version 5.0 aan het eind van mijn script willen zetten. Om te demonstreren sla het volgende script op als vereist versie example.ps1.

Als u dit binnen uw bestaande PowerShell ISE-instantie uitvoert, zou het zonder problemen moeten werken, maar als u het in een oudere versie probeert uit te voeren, zoals PowerShell 2.0, zal het script een fout geven op de regel #requires en de rest van het script nooit uitvoeren. Dit is het gewenste resultaat.

Om te testen zou je ook iets in kunnen voegen als –Version 99.99 en dan krijg je foutmeldingen te zien die lijken op de voorbeelden hieronder, maar ik wilde laten zien hoe dit in de echte wereld zou werken op bestaande systemen en ook laten zien dat je op de commandoregel kunt terugvallen op een eerdere versie van PowerShell.

Om dit te testen, moet u de opdrachtregelversie van PowerShell gebruiken en deze als volgt starten:

Doe vervolgens het bestand dat u hierboven hebt opgeslagenrequires version example.ps1. U zou een fout moeten zien zoals:

Hoewel ik zou aanraden om het commentaar #Requires helemaal aan het begin van het bestand te plaatsen, kun je het in werkelijkheid overal plaatsen en zal het zich op dezelfde manier gedragen. Als je het bovenstaande bestand opnieuw maakt, maar de opmerking naar beneden verplaatst na de Get-Process en opslaat als vereist versie voorbeeld Version 2.ps1.

Probeer het onder versie 2.0 uit te voeren, zoals hierboven, en u krijgt een soortgelijke foutmelding en het hele script zal niet worden uitgevoerd.

Dit betekent dat je niet een deel van een script kunt hebben dat onder een oudere versie kan draaien (of als niet-beheerder kan worden uitgevoerd) en een deel dat een bepaalde versie vereist of dat als beheerder moet worden uitgevoerd. Als je zoiets in code wilt doen, moet je slimmer worden. Sla het volgende script op als Requires version example Version 3.ps1.

Als je dit onder versie 5 of hoger uitvoert, wordt het Process.txt-bestand gemaakt en gezipt. Als je het onder een eerdere versie uitvoert, zoals de –Version 2.0 hierboven, kan het script nog steeds het Process.txt bestand maken omdat Get-Process een cmdlet is dat beschikbaar is in versie 2.0. Aangezien Compress-Archive dat niet is, zal het script die stap overslaan en een foutmelding geven. Het is aan jou of je scripts wilt schrijven die de versie van PowerShell kunnen detecteren en zich afhankelijk van de versie anders gedragen, maar in veel gevallen als je het script gewoon wilt afbreken, is het #Requires commentaar verreweg de gemakkelijkste manier om dingen af te handelen.

Twee laatste caveats bij het gebruik van een #Requires commentaar. Het moet aan het begin van de regel beginnen; er mogen geen spaties of tabs voor staan. Bovendien kun je niet proberen het te slim af te zijn door het als onderdeel van een try/catch blok te plaatsen om het eleganter af te handelen. Sla het volgende script op om beide caveats te illustreren: Vereist versievoorbeeld Versie 4.ps1.

Merk op dat het de #requires op regel 6 is die het script afbreekt, niet die op regel 1, en dat de try/catch geen effect heeft gehad. #Requires zijn globaal en hebben invloed op het hele script, ongeacht waar ze staan, mits ze op de regel beginnen. En ja, u kunt meer dan één #Requires in een script hebben. Je zou kunnen eisen dat een specifieke versie van PowerShell, bepaalde modules aanwezig zijn en dat RunAsAdministrator.

Twee laatste caveats op de #Requires – RunAsAdministrator opmerking. Het is geïntroduceerd in PowerShell versie 4.0 en werkt niet op niet-Windows systemen (ja, onthoud, PowerShell is nu cross-platform!). Sla het volgende script op als Requires Administrator.ps1.Je hebt een Linux instance nodig om dit te testen, maar als je die hebt, kan PowerShell op Linux worden geïnstalleerd met de methoden die hier worden uitgelegd. Eenmaal geïnstalleerd kopieer je het bovenstaande script naar je Linux instance of sla je het op. Om het script uit te voeren kunt u het volgende invoeren:

U zou moeten zien

Tot slot vraagt u zich misschien af of u blokstijlcommentaar kunt gebruiken met #Requires. Uit mijn beperkte tests blijkt dat dit niet werkt. Je moet elke Requires op zijn eigen regel zetten met een voorafgaande #. Dit script werkt wel:

Dit script werkt niet:

Conclusie