Instead of using pause in scripts, it is useful to me to make a script auto-exit after a set time. This is particularly useful to me as various of these scripts can run interactively or as a background task with Start-Process -WindowStyle Hidden where a pause would mean that process could hang around forever, but with the timer, even if it's in the background, it will time out. I was given this solution via this question: PowerShell, break out of a timer with custom keypress
$t = 8; Write-Host "Exiting in $t seconds (press any key to exit now)" -NoNewLine
for ($i=0; $i -le $t; $i++) {
Start-Sleep 1; Write-Host -NoNewLine "."
if ([Console]::KeyAvailable) {
$key = [Console]::ReadKey($true).Key
if ($key) { break }
}
}
However, if I run this with Start-Process -WindowStyle Hidden in the background, PowerShell generates an error due to [Console]::KeyAvailable as there is no console available when running in the background.
Cannot see if a key has been pressed when either application does not have a
console or when console input has been redirected from a file. Try
Console.In.Peek.
At C:\Users\Boss\Install Chrome.ps1:36 char:78
+ ... ep 1; Write-Host -NoNewLine "."; if ([Console]::KeyAvailable) { $key ...
+ ~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [], InvalidOperationExcept
ion
+ FullyQualifiedErrorId : System.InvalidOperationException
• Is there some way that I can adjust the code I have such that it will not generate an error when run in the background, while still retaining the "press any key to exit now" option when run interactively?
• What does Try Console.In.Peek mean?
It is not Start-Process that is the problem:
When a console application is launched on Windows, such as powershell.exe, a console is always allocated - even if it is hidden (-WindowStyle Hidden)
Unless you use -RedirectStandardInput, that console's stdin stream ([Console]::In) is not redirected, as reflected in [Console]::IsInputRedirected returning $false.
Thus, your code would work: [Console]::KeyAvailable would always return $false, and the full timeout period would elapse.
However, you would see the problem with Start-Job:
The background job that is created uses a hidden PowerShell child process to run the code in the background, and the way that the calling PowerShell instance communicates with it is via stdin.
Thus, [Console]::KeyAvailable causes the statement-terminating error you saw, given that one of the causes mentioned in the error message applies: stdin is redirected (but a console does exist).
Workarounds:
Simply make the use of [Console]::KeyAvailable conditional on [Console]::IsInputRedirected returning $false:
$t = 8; Write-Host "Exiting in $t seconds (press any key to exit now)" -NoNewLine
for ($i=0; $i -le $t; $i++) {
Start-Sleep 1; Write-Host -NoNewLine "."
# Note the use of -not [Console]::IsInputRedirected
if (-not [Console]::IsInputRedirected -and [Console]::KeyAvailable) {
$key = [Console]::ReadKey($true).Key
if ($key) { break }
}
}
Alternatively, use your code as-is and use a thread job instead, using Start-ThreadJob, which comes with PowerShell (Core) 7+ and in Windows PowerShell can be installed on demand with, e.g., Install-Module ThreadJob -Scope CurrentUser:
Start-ThreadJob { & 'C:\Users\Boss\Install Chrome.ps1' }
Thread jobs, if available, are generally preferable to regular, child-process-based background jobs, due to being faster and more light-weight.
Since the use of stdin only applies to inter-process communication, [Console]::KeyAvailable doesn't cause an error in a thread job, and - commendably - only pays attention to key strokes when the thread at hand is the foreground thread.