What To Do / Not To Do in PowerShell: Part 6. 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. What To Do / Not to Do in PowerShell: Part 9. 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. 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. As a bonus, if anyone (even me) modifies your script, it breaks the signature. What To Do / Not to Do in PowerShell: Part 3.
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? Take a look at this code: 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. What To Do / Not to Do in PowerShell: Part 4. 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. What To Do / Not to Do in PowerShell: Part 7. 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. 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. What To Do / Not to Do in PowerShell: Part 10. 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. What To Do / Not to Do in PowerShell: Part 12. 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. What To Do / Not to Do in PowerShell: Part 2. 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.