What To Do / Not To Do in PowerShell: Part 6 | PowerShell with a Purpose Blog. It's extremely common for programmers and scripters to use comments in their scripts. Inline comments help to explain what the script is doing, and provides a clue to whoever comes in later down the line as to what the author was thinking. I say, "Stop using them. " Yes, you read correctly: Stop using inline comments. Why? Well, because the only benefit someone reading the code. To that end, I suggest using Write-Verbose and Write-Debug for your comments. Okay, okay, you'll probably still have a use for plain old comments. What To Do / Not to Do in PowerShell: Part 9 | PowerShell with a Purpose Blog.
You probably know that Windows PowerShell supports code-signing, a means of protecting users and ourselves against theunintentional execution of untrusted scripts. Heaven knows, half of y'all have probably set your shell's ExecutionPolicy to "Unrestricted," and are touching up your makeup even know for your appearance on CNN: "Gosh durn it, that Microsoft stuff just whacked my whole 'vironment, it did! We're a-switchin' to the Google! " Another choice would be the RemoteSigned execution policy which, frankly, I don't care for. It basically only requires a signature for scripts that (a) live on a remote computer or (b) were downloaded through IE or Outlook. Not much extra security for me, there.
My choice is AllSigned, which requires all scripts to carry a signature. Yep, it's a bit less convenient, but I like the security it offers me. But I ask: Why aren't more of you signing your scripts? Okay, to be fair, signing does require a Class 3 Authenticode code-signing certificate. What To Do / Not to Do in PowerShell: Part 3 | PowerShell with a Purpose Blog. Take a look at the left-hand side of your keyboard.
Odds are, you'll find a key labeled "Tab," or perhaps a key with a "->" symbol on it. Also notice a key labeled "Enter" or "Return," and that big, blank key at the ver bottom. Please make these keys your friend. Why? Pretty awful, isn't it? Now, isn't this version much easier to read and interpret? The difference? It's just a bit of whitespace, but it makes all the difference in the world. What To Do / Not to Do in PowerShell: Part 11 | PowerShell with a Purpose Blog. What To Do / Not to Do in PowerShell: Part 4 | PowerShell with a Purpose Blog. Can you tell me what the following command does? Gwmi win32_logicaldisk -fi 'drivetype=3' -com $x | ?
{ $_.freespace -lt 1gb } | % { $_.chkdsk() } If you're a real PowerShell aficionado, you probably can. Newcomers, not so much. And either way, you have to spend a lot of time starting at it. Get-WmiObject -class Win32_LogicalDisk -filter 'DriveType=3' -computername $computer | Where-Object -filterScript { $_.FreeSpace -lt 1GB } | ForEach-Object -process { $_.ChkDsk() } Probably a lot easier to figure out. Srsly, will b ur bff if u do it rite. What To Do / Not to Do in PowerShell: Part 7 | PowerShell with a Purpose Blog. Windows PowerShell is pretty flexible. For example, you can use either a forward / slash or a back \ slash as a path separator. It also lets you use 'single' or "double" quotation marks for strings (I recently saw someone refer to them as 'speech marks,' which I thought was neat). But do you know the difference? Inside "double quotes" only, PowerShell will do two special things: Look for the backtick ` escape character, and escape whatever follows it.
This lets you, for example, use `t as a tab character.Look for the dollar sign, and assume that whatever $follows to the next white space is a variable name, and then replace it with the variable's contents. So "$this" or "${this is also legal}" would be replaced. None of this happens inside 'single' quotes. Verbose or Debug. This morning there was some discussion on Twitter about when to use Write-Verbose and when to use Write-Debug. They both can provide additional information about what your script or function is doing, although you have to write the code.
Typically, I use Write-Verbose to provide trace and flow messages. When enabled, it makes it easier to follow what the script is doing and often the messages include variable information. Write-Debug is helpful for providing detailed debug messages, but it also has the effect of turning on debuggging when you include it. Here’s a sample script that uses both cmdlets. [cc lang="PowerShell"] #requires -version 2.0 [cmdletbinding()] Param([string]$computername=$env:computername) $start=Get-Date Write-Verbose “Starting $($myinvocation.mycommand)” Write-Debug “`$computername is $computername” Write-Verbose “Connecting to $computername” The script can use the common -Verbose and -Debug common parameters because I include the [cmdletbinding()] attribute.
Like this: What To Do / Not to Do in PowerShell: Part 10 | PowerShell with a Purpose Blog. Why? Consistency. As an admin, I know what a Get cmdlet does. I know what to expect from Invoke, Write, Out, Format, Export, Set, New, and so forth. Throw me some weird verb like "instantiate" and I'll have no clue what to expect. I won't be able to discover that cmdlet on my own, either, because it doesn't have one of the standard verbs.
Consistency in cmdlet names (as well as parameter names) is a key to helping people use your command more easily and effectively. What's more, you shoudl get in the habit of appending some company-level prefix to your nouns. What To Do / Not to Do in PowerShell: Part 12 | PowerShell with a Purpose Blog. Reach into your mind, and find the part that knows about the Write-Host cmdlet. Now, delete that part. Write-Host is usable only for outputting information directly to the screen, not the pipeline. Data written to the screen can't be exported to XML or CSV, can't be converted to HTML, can't be formatted in different ways - in other words, it's useless. I'm not trying to get up in your religion or anything, but if you use Write-Host... well, odds are your soul is in jeopardy. The correct way to output information from a PowerShell cmdlet or function is to create an object that contains your data, and then to write that object to the pipeline by using Write-Output.
For example, let's say you've collected five piece of information into some variables, named $x1, $x2, $x3, $x4, and $x5. $info = { 'Computername'=$x1; 'OSVersion'=$x2; 'Whatever'=$x3; 'ThisInfo'=$x4; 'ThatInfo'=$x5 } Write-Output (New-Object -Type PSObject -Prop $info) That's how you do it. See? Output objects. What To Do / Not to Do in PowerShell: Part 2 | PowerShell with a Purpose Blog. If you're looking at, or writing, a PowerShell script, then you shouldnever see this anywhere in the file: $ErrorActionPreference = 'SilentlyContinue' Man, that makes me mad. What it's doing is shutting off error messages for the entire script - even the beneficial, "this is broken" error messages that you NEED to see in order to ensure the script is operating correctly or can be fixed. Folks will throw that evil line into a script because the script contains a command or two where they're anticipating an error, and they don't want the error messing up their script's output.
I get that - but this is the wrong way to do it. What to do instead? If you have a command that you think might cause an error, and you want to suppress the error for that one command, there's a better way. Del -Path $logfile -ErrorAction 'SilentlyContinue' Of course, I have to remember that I'd also be suppressing "Access Denied" errors, along with any other error that might occur when running that command.