-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should Write-Host still be avoided? #1118
Comments
We could consider running the rule only on version 3 and 4 using e.g. condition compilation of the rule, so yes version specific rules are possible. |
Cool. I agree that it probably still gets misused a lot. The big benefit of Write-Host is that it supports output in different colors which can be a valuable way to display different types of information with scripts that people will be interacting with/running manually. I see the file for this rule in the repo: I assume the change would be right around the section that skips the rule for cmdlets that start with the Show verb? Something like also skipping the rule if the PS version is <5? I'm not too familiar with C, but I'm happy to take a shot at modifying the rule. :) |
It's worth noting that It's no longer impossible to suppress, but I still wouldn't recommend using it outside of very specific scenarios.
Something to keep in mind with that, it's not uncommon to develop a script on a machine with PSv5+, while targeting an older version. |
I have also gone to write-information as well. |
Ok, so concluding, is it the best to just add more information to the documentation. Would everyone be happy with that? |
What about analyzing if Write-Host is using -ForegroundColor or -BackgroundColor and the cmdlet is not used in the context of a function? There are legitimate reasons to provide feedback to an end-user with color in a script. It is unfortunate that the verb is wrong as Show-Host would be more appropriate. Write-Information does not have -ForegroundColor or -BackgroundColor arguments. |
@roberttoups Most of the cases that the rule is specifically designed to advise against include color. The idea is that generally what is written to host isn't actually necessary by default. If there is a problem, write an error, otherwise either do nothing or write output. If you want to include extra information, write it to an optional stream like information or verbose. It's not never useful, but in the few cases were it's the best pattern to use, suppressing the warning works great.
The rule doesn't warn when the parent function has the |
Thank you for the prompt and detailed feedback. While I disagree with sentiment that color lacks value to an end-user as a means of feedback and should be discouraged, I understand your statement in regards to errors or problems completely. I agree that information should stored in a stream. Not everything I wish to convey is a problem or error and Is there a reason that Set-StrictMode -Version 'Latest'
$InformationPreference = 'Continue'
$VerbosePreference = 'Continue'
Start-Transcript -Path (Join-Path -Path '.' -ChildPath 'Test-Output.txt')
for ($i = 0; $i -le 100; $i++) {
Write-Progress -PercentComplete $i -Activity 'Progress Bar' -Status "Incremented Number: $i"
Write-Verbose -Message "Verbose: $i"
Write-Information -MessageData "Information: $i"
Start-Sleep -Milliseconds 100
}
Write-Progress -Activity 'Incrementing Number' -Status 'Done' -Completed
Stop-Transcript |
I get the impression that this isn't @SeeminglyScience's intended inference. Colour is perfectly valuable, but no matter what colour you use,
One point is that
There's no need to endure the warnings though! PSSA has some defaults, but they're not dictums. A configuration file or an invocation with |
So it really depends on what you're doing. If you're writing a "controller script" that is only ever gonna be someone double clicking a bat file that invokes the script, sure go wild. If you're writing a reusable command though, that's when it starts to be a bit noisy. For instance, imagine if Basically if anything is ever going to call your script that isn't a user in a console window specifically launched to run your script, it's probably better to keep your output clean.
It's not permanent, it's cleared from the screen between prompts and when the |
Also
Adding onto what @rjmholt said, I'm very excitedly awaiting the arrival of color in the formatting system. Color is fantastic, PowerShell just doesn't support it well yet. |
Thanks for all the feedback. I appreciate the time and effort in educating me on the mindset behind the rule and some of the under the hood PowerShell information. |
Support would likely come from the formatting system, not |
Interestingly, I just attended a PowerShell Meetup hosted by Doug Finke which had James Brundage's discussion of PowerShell Formatting and his Module EZout https://github.com/StartAutomating/EZOut. He demonstrated color in output using formatting. |
The objections against #Requires -Version 5
$InformationPreference = "Continue"
if ($InformationPreference -ne "SilentlyContinue") { Write-Host "Foo" -f Green } |
It's always been recommended to avoid using Write-Host because it outputs only to the console and not to any of the standard output streams. As of PowerShell 5.0, Write-Host is just a wrapper for Write-Information and thus outputs to the standard output streams similar to the other Write-* cmdlets.
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/write-host?view=powershell-6
Should the use of Write-Host still be flagged as something to be avoided? Is it possible to implement a rule that only flags the use of Write-Host if the computer is running a version of PowerShell earlier than 5.0?
Thanks!
The text was updated successfully, but these errors were encountered: