Tag Archives: $true

Forcing a Switch Parameter to be False

The coworker that sits next to me at the office has upped his PowerShell game tremendously since he’s moved up from Operations to the Windows Team. He often has well-thought-out questions and he’s long shown a great desire to learn about PowerShell. It’s addictive and rewarding, so there’s no question as to why. He may not know it, but I look forward to the questions. The need for PowerShell answers here and there keeps me fresh, and so while it benefits him, it benefits me too.

As he does, he asked a question recently. It was in regard to the Confirm parameter. Why does it need the colon and $false to not be true? Why does it need to be written like this: -Confirm:$false? Why can’t it be written like this: -Confirm $false?

If a switch parameter is included, then its value is $true. If it’s not included, its value is $false. Knowing that alone, makes it clear that we’d have to force something to be false if its default is $true. Okay, knowing that, why can’t we do this then: -Confirm $false?

It’s got to do with the PowerShell parser. It’s how the engine evaluates the statement. Remember, it’s a switch parameter. The parameter is either included or it’s not. The switch parameter is inherently never dependent on a value to be included with it. It doesn’t work that way. The PowerShell engine will see -Confirm and make it $true, long before it even sees the $false value. The colon and value being attached to the Confirm parameter ensures the parser knows you want it to be of that specific value.

Keep an Attached Drive Active

I recently received two drives sent via FedEx for a rather large data copy. Maybe I haven’t been looking, but I’ve never seen anything like these drives before, although it wasn’t too difficult to believe they existed. They each hold 6TB and have a 10-key keypad on the drive case where you have to punch in a PIN to unlock the drive. Neat, except that the drives also have a timeout period in which they automatically lock. To unlock each drive, providing there’s been no disk activity, as that’s what starts┬áthe timeout counter, is a trip to the data center to enter the PIN again.

keep-an-attached-drive-active01

A coworker and I quickly arrived at the same idea in order to keep the drives active. I bet you just thought of an idea, too. It’s extremely simplistic, but that’s typically the road on which I travel. In the simple Do-While loop below, we created a file on each of the attached drives. In my example, the loop slept for eight minutes after it created the file. Then it removed the files and slept for another 10 seconds before repeating.

Do {
    New-Item -Path E:\keepalivefile.txt,F:\keepalivefile.txt -ItemType File | Out-Null
    Start-Sleep -Seconds 480 # equal to 8 minutes
    Remove-Item -Path E:\keepalivefile.txt,F:\keepalivefile.txt
    Start-Sleep -Seconds 10
}
While ($true)

That’s all I’ve got tonight, other than to say, I have no idea what I would’ve done if I didn’t know Windows PowerShell. Seriously, how would I have been able to guarantee the drives wouldn’t lock, besides to manually create the disk activity? Keeping File Explorer open wasn’t enough, I tried. PowerShell to the rescue. Again.