I have written my own Powershell logging function Log with parameters stream (on which stream to write the message) and message (the message to write).
The idea is that i can write the outputs both to the console and to a log-file. What I do in the function is basically determine on which stream to publish the message (with a switch statement) and then write the message to the stream and the log-file:
switch ($stream) {
Verbose {
Write-Output "$logDate [VERBOSE] $message" | Out-File -FilePath $sgLogFileName -Append
Write-Verbose $message
break
}
}
The question is now, is it possible to check if the -Verbose argument was given?
The goal is to write the message to the log-file only if the -Verbose was given.
I looked already in the following help docs but didn't find anything helpful:
- help about_Parameters
- help about_commonparameters
Also, the -WhatIf parameter does not work with Write-Verbose.
Thanks a lot for your answers!
Inside your script check this:
$PSCmdlet.MyInvocation.BoundParameters["Verbose"].IsPresent
Also available: Check the parameter '$VerbosePreference'. If it is set to 'SilentlyContinue' then $Verbose was not given at the command line. If it is set to '$Continue' then you can assume it was set.
Also applies to the following other common parameters:
Name Value
---- -----
DebugPreference SilentlyContinue
VerbosePreference SilentlyContinue
ProgressPreference Continue
ErrorActionPreference Continue
WhatIfPreference 0
WarningPreference Continue
ConfirmPreference High
Taken from an MSDN blog page from long ago... so it should be relevant with relatively old versions of Powershell. Also see "Get-Help about_CommonParameters" in Powershell v4.
More generally: since one might specify -Verbose:$false on the command line, the following code handles that case. It also works for any other switch parameter:
$Verbose = $false
if ($PSBoundParameters.ContainsKey('Verbose')) { # Command line specifies -Verbose[:$false]
$Verbose = $PsBoundParameters.Get_Item('Verbose')
}
Came across this looking for the same answer and found some good info, also some not so good.
The marked answer seems to be dated and not correct as the comments stated. The PSBoundParameter property object from the MyInvocation object is a Dictionary (PoSH 5.1 up maybe earlier didn't check) which does not contain the IsPresent property. The asker also forgot to consider $VerbosePreference where other answers have presented this option.
Here's a solution that makes it simple and easy:
if ( $PSBoundParameters['Verbose'] -or $VerbosePreference -eq 'Continue' ) {
# do something
}
$PSBoundParameters is a hashtable object, if the value is present and true it will evaluate to true, if it is not present or present and not true it will evaluate to false. VerbosePreference which is set at the session level will display verbose statements when the value is Continue. Put this together in a condition using a logical or and you will get an accurate representation if verbose output is desired.
If you're determining whether or not to print depending on the value of the -Verbose parameter, consider using Write-Verbose instead of Write-Host: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/write-verbose?view=powershell-7.1
Related
I want to print a Warning in PowerShell as a prompt and then read the answer on the same line. The problem is that Write-Warning prints a newline at the endof the message, and one alternative, Read-Host -Prompt, doesn't print the prompt to the warning stream (or print in yellow). I've seen Write-Warning -WarningAction Inquire, but I think that's a little verbose and offers options I don't want.
The best I've done is:
$warningMsg= "Something is wrong. Do you want to continue anyway Y/N? [Y]:"
Write-Host -ForegroundColor yellow -NoNewline $warningMsg
$cont = Read-Host
This works great--prints the yellow prompt and then reads the input on the same line--but I'm wondering about the warnings I've seen against using Write-Host, if it's more appropriate to figure out some way to print to the warning stream without a newline. Is there a way to do that? I've noticed that Write-Host seems to be a wrapper to write to the Info stream, but I don't see any way to write to warnings without a new line ([Console]::Warning.WriteLine() doesn't exist for example).
You can't do what you want with Write-Warning.
Therefore, I will answer regarding your other concern.
Write-Host is perfectly fine to use in a PowerShell 5+ script.
If you look at the articles recommending against its use, you will notice that the vast majority (if not all) were written before the introduction of PowerShell 5.
Nowadays, Write-Host is a wrapper around Write-Information.
The official documentation confirms this:
Starting in Windows PowerShell 5.0, Write-Host is a wrapper for
Write-Information This allows you to use Write-Host to emit output to
the information stream. This enables the capture or suppression of
data written using Write-Host while preserving backwards
compatibility.
The $InformationPreference preference variable and -InformationAction
common parameter do not affect Write-Host messages. The exception to
this rule is
-InformationAction Ignore, which effectively suppresses
Write-Host output.
Writing to the information stream using Write-Host and / or Write-information won't create problems with your output string.
Stream # Description Introduced in
1 Success Stream PowerShell 2.0
2 Error Stream PowerShell 2.0
3 Warning Stream PowerShell 3.0
4 Verbose Stream PowerShell 3.0
5 Debug Stream PowerShell 3.0
6 Information Stream PowerShell 5.0
* All Streams PowerShell 3.0
Bonus
You can also control the visibility of the information stream if you use an advanced function through the -InformationAction parameter, provided you also bind the given parameter value to the Write-Host statements in the function.
For instance, if you wanted to disable the Information stream by default unless requested otherwise:
function Get-Stuff {
[CmdletBinding()]
param ()
if (!$PSBoundParameters.ContainsKey('InformationAction')) {
$InformationPreference = 'Ignore'
}
Write-Host 'This is the stuff' -InformationAction $InformationPreference -ForegroundColor Green
}
# Hidden by default
Get-Stuff
# Force it to show
Get-Stuff -InformationAction Continue
Note
While technically it is not possible to use Write-Warning -NoNewLine, you could look into manipulating the cursor position and resetting it to the end of the previous line, therefore doing the same.
However, I have limited experience with that and my observations regarding the subject were that you might end up having to create exceptions to comply with limitations of some console environments. In my opinion, this is a bit overkill...
Additional references
About_redirections
I would like to set up a variable in my code that would ultimately define if I'll see some output or not.
"hello" writes to stdout
"hello" > $null supresses output
My idea is something like this:
$debugOutputSwitch = $true
$outputVar = $null
if ($debugOutputSwitch){ $outputVar = **STDOUT** }
...
Write-Host "Something I want out anyway"
"Something I might not want on STDOUT" > $outputVar
If this general idea is a way to go, then STDOUT is what I'm looking for
If this idea is completely wrong...well...then I'm lost
What you want to read up on are output streams and redirection in Powershell. This includes information on all of the different output streams and how to control their relevance using built-in constructs. Just like there are the Write-Host and Write-Output cmdlets, there are also several others that control which stream to write to.
About the Output Streams
There are 6 streams in total. Make note of their numbers, because these stream identifiers are used to control which streams to redirect:
1 - Success Stream - This stream is used when passing information along the Powershell Pipeline. This is the "default" stream, but can also be written to with Write-Output.
2 - Error Stream - Errors should be written to this stream. Can be written to with Write-Error, accompanied by further error information.
3 - Warning Stream - Used to write warning information. Can be written to withWrite-Warning.
4 - Verbose Stream - Used to write verbose output. Does not display by default but can be made to display by either setting $VerbosePreference = "Continue", or by using the [CmdletBinding()] attribute on a function or script and passing in the -Verbose flag. Write to the verbose stream with Write-Verbose.
5 - Debug Stream - Used to write to the debug stream, and optionally trigger a breakpoint. Does not display or trigger a breakpoint by default, but can be controlled with the $DebugPreference variable, or by using the [CmdletBinding()] attribute on a script or function and using the -Debug flag. You can write to the debug stream by using theWrite-Debug cmdlet.
6 - Information Stream - Can be written to by Write-Host. This is the console host output and is not part of the pipeline.
Redirecting Streams
You can use redirection operators to redirect other streams to the success stream as well. Each stream above has a number associated with it. This is the numeric representation of each stream.
The redirection operators are as follows:
> - Redirect success stream to file (overwrite)
#> - Redirect the # stream to file (e.g. 2> somefile.txt)
>> - Redirect success stream to file (appends, you can also use a numbered stream as with the overwrite file operator)
>&1 - Redirect any stream to success stream (note that unlike the other redirection operators you can only redirect to the success stream. Using other stream identifiers will result in an error).
Also note that in place of a stream number, you can use * which will redirect all streams at the same time.
Here are some examples of redirecting output from one stream to another (if you're familiar with it, it's somewhat UNIX-y):
# Write success stream to file
Write-Output "Here is some text for a file" > .\somefile.txt
# Write error stream to file (you have to first
Write-Error "Some error occurred" 2> .\somefile.txt
# Redirect all error output to the success stream
$myErrorOutput = Write-Error "My error output" 2>&1
# Append all script output streams to a single file
Get-OutputFromAllStreams.ps1 *>> somefile.txt
Output to a File and the Pipeline Simultaneously
You can redirect the output stream to a file and the pipeline at the same time as well, using the Tee-Object cmdlet. This also works with variables, too:
$myString = "My Output" | Tee-Object -FilePath .\somefile.txt
$myString2 = "My Output 2" | Tee-Object -Variable varName
Sample function to show how to use the different Write- cmdlets
Note how the following function is decorated with the [CmdletBinding()] attribute. This is key in making the -Verbose and -Debug switches work without you having to define them yourself.
function Write-DifferentOutputs {
[CmdletBinding()]
# These all visible by default but only the output stream is passed down the pipeline
Write-Output "Output stream"
Write-Warning "Warning stream"
Write-Error "Error stream"
Write-Host "Information stream"
# These are not visible by default, but are written when the `-Verbose` or `-Debug` flags are passed
# You can also manually set the $VerbosePreference or $DebugPreference variables to control this without parameters
Write-Verbose "Verbose stream"
Write-Debug "Debug stream"
}
Call the above function with the -Verbose or -Debug switches to see how the behavior differs, and also call it with neither flag.
Redirecting output to $null if you really need to
If there is output that you never want to see or for some other reason using the Write- cmdlets to write to the Verbose or Debug streams isn't an option, you can still redirect output to $null or make use of the Out-Null cmdlet. Recall the numbered streams at the top of this answer, they will be referenced here:
Using redirection
# Don't forget that *> redirects ALL streams, and may be what you want
Write-Output 'Success Stream' > $null
Write-Error 'Error Stream' 2> $null
Write-Warning 'Warning Stream' 3> $null
Write-Verbose 'Verbose Stream' 4> $null
Write-Debug 'Debug Stream' 5> $null
Write-Host 'Information Stream (yes you can suppress/redirect me)' 6> $null
You can also redirect target streams per command: The following example (using the earlier Write-DifferentOutputs function) redirects all streams except for the Error and Success streams:
Note: You are not limited to redirecting targeted streams only to $null.
Write-DifferentOutputs 6>$null 5>$null 4>$null 3>$null
Using Out-Null
Remember, you can redirect other streams to the success stream by redirecting the output to &1.
# Remember, to pass information on the pipeline
# it MUST be on the success stream first
# Don't forget that *> redirects ALL streams, and may be what you want
Write-Output 'Success Stream' | Out-Null
Write-Error 'Error Stream' 2>&1 | Out-Null
Write-Warning 'Warning Stream' 3>&1 | Out-Null
Write-Verbose 'Verbose Stream' 4>&1 | Out-Null
Write-Debug 'Debug Stream' 5>&1 | Out-Null
Write-Host 'Information Stream (yes you can suppress/redirect me)' 6>&1 | Out-Null
When using Out-Host is appropriate ("Don't Cross the Streams")
Warning: Unlike Write-Host, Out-Host does not output to the information stream. Instead, it outputs directly to the host console. This makes redirection of anything written directly to Out-Host impossible short of using Start-Transcript or using a custom PowerShell host. Note that information written to the console host is still visible to external applications which may be watching the output of PowerShell, as ultimately evenOut-Host output makes it to STDOUT.
Calling yourself Out-Host is usually redundant. By default, PowerShell sends all unassigned output on the success stream here via way of the Out-Default cmdlet (which you should never callOut-Default directly). That said, one useful invocation of Out-Host is to synchronously output formatted object data to the console:
Note: You can redirect information from other output streams and output to Out-Host as well, but there is no reason to do so. Object data will only remain intact on the success stream, the other streams will first convert an object to its ToString() representation prior to redirection. This is also why piping the object to Out-Host in this case is preferable to Write-Host.
Get-Process msedge | Out-Host
One of the caveats of the different output streams is that there is no synchronicity between streams. Normally this is not an issue as PowerShell executes instructions line by line in order, and with the exception of Write-Output success stream this is not a problem with the other streams. However, many types will have a computed for-display attribute which is computed asynchronously from the script execution before the information is sent to Out-Default.
This can result in the displayed object data being intermingled with other output streams which are written to the console host. In some cases, this can even result in loss of information written to the console. "Crossing the streams", if you will, as it pertains to how the rendered output may look.
Consider the following example and output. This does not showcase the streams intermingling, but consider the trouble you would have parsing the output externally if Write-Host "end `n" were written in the middle of the table:
Write-Host "start `n"
Get-LocalUser
Write-Host "end `n"
And the output:
start
end
Name Enabled Description
---- ------- -----------
Administrator True
DefaultAccount False A user account managed by the system.
Disabled False Built-in account for guest access to the computer/domain
In particular this is problematic for types which define a table format that must calculate the column width before sending the formatted data to Out-Host for display. Types which pre-define the table width or do not format output as a table at all do not have this problem. Out-Default can take up to 300ms to calculate column width.
When Out-Host is called explicitly as part of a pipeline, however, the table width calculation is skipped for these objects as the object data never makes it to Out-Default. This is useful primarily to ensure that object data intended to be written to the console is done so in the correct order. The downside is that table columns may not be wide enough to accommodate all of your data on each row.
This all said, if you must process the console output of a script, it is recommended to format the data you wish to process into a string and use Write-Host instead, or use another method to get the data somewhere suitable for external processing. for-display formatting is not intended for use with external processing.
#mklement1's answer here dives further into the details about this if you are curious to learn more about this problem.
Redirecting whole command outputs to Write- cmdlets
You can easily pipe all output of a command or cmdlet to one of the Write- cmdlets. I'll use the Write-DifferentOutputs provided earlier in my example below, but this will work with any cmdlet, script, or command you run:
Write-DifferentOutputs *>&1 | Write-Verbose
What the above will do is only show the command output if $VerbosePreference = $Continue, or if you passed -Verbose as an argument to your script or function.
In Summarium
In your original question, you are attempting to reinvent a wheel that Powershell already supports fairly well. I would suggest that you learn how to make use of the different Write-Output cmdlets for each stream and especially learn how to make use of the Write-Warning, Write-Verbose, Write-Error, and Write-Debug cmdlets.
All right.
Thanks to all the brainiacs here for the motivation.
This answer may not be the best way to go about it, but it works!
Two things you need to understand to achieve this:
If you are used to using Write-Host, it won't work, you'll have to go with Write-Output.
You may have to learn to use a block of script as a function parameter.
One is self explanatory, so here's how to attain #2:
Function Test-SctiptBlockParam {
Param(
$scriptblock
)
if ($debugOutput) {
Invoke-Command $scriptblock
} else {
(Invoke-Command $scriptblock) > $null
}
}
Test-SctiptBlockParam -scriptblock { Write-Output "I want to see on the STDOUT sometimes" }
Finally, here is an example of my output and code
I'm writing a script that (by necessity) has to call a rather noisy set of other cmdlets. I'd like to the printing from the other cmdlets to not be displayed so I only see the status messages from my own script.
I've tried > $null and | Out-Null, but those only swallow returned values, not text printed via Write-Host. How can I hide/prevent text being printed "down the stack"?
Try to define your dummy function Write-Host before calling noisy cmdlets, e.g.
function Write-Host {}
If they call Write-Host literally then this should help.
If I've read your post correctly, you'd like to silence the Write-Host cmdlet. If we consider command precedence, we know that functions will be run before cmdlets, if they have the same name. Therefore, I'd recommend you create a Write-Host function that doesn't write anything. Here's an example that highlights this possibility.
I'm writing a function in PowerShell that I want to be called via other PowerShell functions as well as be used as a standalone function.
With that objective in mind, I want to send a message down the pipeline using Write-Output to these other functions.
However, I don't want Write-Output to write to the PowerShell console. The TechNet page for Write-Output states:
Write-Output:
Sends the specified objects to the next command in the pipeline. If the command is the last command in the pipeline, the objects are displayed in the console.
-NoEnumerate:
By default, the Write-Output cmdlet always enumerates its output. The NoEnumerate parameter suppresses the default behavior, and prevents Write-Output from enumerating output. The NoEnumerate parameter has no effect on collections that were created by wrapping commands in parentheses, because the parentheses force enumeration.
For some reason, this -NoEnumerate switch will not work for me in either the PowerShell ISE or the PowerShell CLI. I always get output to my screen.
$data = "Text to suppress"
Write-Output -InputObject $data -NoEnumerate
This will always return 'Text to suppress' (no quotes).
I've seen people suggest to pipe to Out-Null like this:
$data = "Text to suppress"
Write-Output -InputObject $data -NoEnumerate | Out-Null
$_
This suppresses screen output, but when I use $_ I have nothing in my pipeline afterwards which defeats the purpose of me using Write-Output in the first place.
System is Windows 2012 with PowerShell 4.0
Any help is appreciated.
Write-Output doesn't write to the console unless it's the last command in the pipeline. In your first example, Write-Output is the only command in the pipeline, so its output is being dumped to the console. To keep that from happening, you need to send the output somewhere. For example:
Write-Output 5
will send "5" to the console, because Write-Output is the last and only command in the pipeline. However:
Write-Output 5 | Start-Sleep
no longer does that because Start-Sleep is now the next command in the pipeline, and has therefore become the recipient of Write-Output's data.
Try this:
Write your function as you have written it with Write-Output as the last command in the pipeline. This should send the output up the line to the invoker of the function. It's here that the invoker can use the output, and at the same time suppress writing to the console.
MyFunction blah, blah, blah | % {do something with each object in the output}
I haven't tried this, so I don't know if it works. But it seems plausible.
My question is not the greatest.
First of all Write-Output -NoEnumerate doesn't suppress output on Write-Output.
Secondly, Write-Output is supposed to write its output. Trying to make it stop is a silly goal.
Thirdly, piping Write-Output to Out-Null or Out-File means that the value you gave Write-Output will not continue down the pipeline which was the only reason I was using it.
Fourth, $suppress = Write-Output "String to Suppress" also doesn't pass the value down the pipeline.
So I'm answering my question by realizing if it prints out to the screen that's really not a terrible thing and moving on. Thank you for your help and suggestions.
Explicitly storing the output in a variable would be more prudent than trying to use an implicit automatic variable. As soon as another command is run, that implicit variable will lose the prior output stored in it. No automatic variable exists to do what you're asking.
If you want to type out a set of commands without storing everything in temporary variables along the way, you can write a scriptblock at the command line as well, and make use of the $_ automatic variable you've indicated you're trying to use.
You just need to start a new line using shift + enter and write the code block as you would in a normal scriptblock - in which you could use the $_ automatic variable as part of a pipeline.
Kind of like <statement> || die in perl, something concise that I can put with every critical statement to avoid bothering powershell with the rest of the script if something goes wrong.
Most commands support the -ErrorAction common parameter. Specifying -ErrorAction Stop will generally halt the script on an error. See Get-Help about_CommonParameters.
By default, -ErrorAction is Continue. You can change the default option by changing the value of $ErrorActionPreference. See Get-Help about_Preference_Variables.
If verbosity is really an issue, -ErrorAction is aliased to -ea.
Another way to implement a ...|| die-like construct in PowerShell without the need to add huge try-catch constructs, would be to use the automatic variable $?.
From Get-Help about_Automatic_variables:
$?
Contains the execution status of the last operation. It contains
TRUE if the last operation succeeded and FALSE if it failed.
Simply add the following right after each critical statement:
if(-not $?){
# Call Write-EventLog or write $Error[0] to an xml or txt file if you like
Exit(1)
}