I am running a PowerShell script from within a batch file. The script fetches a web page and checks whether the page\'s content is the string \"OK\".
The PowerShell
I think in this case you will need Write-Output.
If you have a script like
Write-Output "test1";
Write-Host "test2";
"test3";
then, if you call the script with redirected output, something like yourscript.ps1 > out.txt
, you will get test2
on the screen test1\ntest3\n
in the "out.txt".
Note that "test3" and the Write-Output line will always append a new line to your text and there is no way in PowerShell to stop this (that is, echo -n
is impossible in PowerShell with the native commands). If you want (the somewhat basic and easy in Bash) functionality of echo -n
then see samthebest's answer.
If a batch file runs a PowerShell command, it will most likely capture the Write-Output command. I have had "long discussions" with system administrators about what should be written to the console and what should not. We have now agreed that the only information if the script executed successfully or died has to be Write-Host
'ed, and everything that is the script's author might need to know about the execution (what items were updated, what fields were set, et cetera) goes to Write-Output. This way, when you submit a script to the system administrator, he can easily runthescript.ps1 >someredirectedoutput.txt
and see on the screen, if everything is OK. Then send the "someredirectedoutput.txt" back to the developers.
Write-Host "Found file - " + $File.FullName -ForegroundColor Magenta
Magenta can be one of the "System.ConsoleColor" enumerator values - Black, DarkBlue, DarkGreen, DarkCyan, DarkRed, DarkMagenta, DarkYellow, Gray, DarkGray, Blue, Green, Cyan, Red, Magenta, Yellow, White.
The + $File.FullName
is optional, and shows how to put a variable into the string.
Simply outputting something is PowerShell is a thing of beauty - and one its greatest strengths. For example, the common Hello, World! application is reduced to a single line:
"Hello, World!"
It creates a string object, assigns the aforementioned value, and being the last item on the command pipeline it calls the .toString()
method and outputs the result to STDOUT
(by default). A thing of beauty.
The other Write-*
commands are specific to outputting the text to their associated streams, and have their place as such.
You can use any of these in your scenario since they write to the default streams (output and error). If you were piping output to another commandlet you would want to use Write-Output, which will eventually terminate in Write-Host.
This article describes the different output options: PowerShell O is for Output
What would be the right thing to use to write to the Windows equivalent of stdout?
In effect, but very unfortunately, both Windows PowerShell and PowerShell Core as of v7.0, send all of their 6(!) output streams to stdout when called from the outside, via PowerShell's CLI.
See this GitHub issue for a discussion of this problematic behavior, which likely won't get fixed for the sake of backward compatibility.
In practice, this means that whatever PowerShell stream you send output to will be seen as stdout output by an external caller:
E.g., if you run the following from cmd.exe
, you'll see no output, because the stdout redirection to NUL
applies equally to all PowerShell streams:
C:\>powershell -noprofile -command "Write-Error error!" >NUL
However - curiously - if you redirect stderr, PowerShell does send its error stream to stderr, so that with 2>
you can capture the error-stream output selectively; the following outputs just 'hi'
- the success-stream output - while capturing the error-stream output in file err.txt
:
C:\>powershell -noprofile -command "'hi'; Write-Error error!" 2>err.txt
The desirable behavior is:
1
) to stdout.Send output from all other streams to stderr, which is the only option, given that between processes only 2 output streams exist - stdout (standard output) for data, and stderr (standard error) for error messages and all other types of messages - such as status information - that aren't data.
It's advisable to make this distinction in your code, even though it currently isn't being respected.
Inside PowerShell:
Write-Host
is for display output, and bypasses the success output stream - as such, its output can neither be (directly) captured in a variable nor suppressed nor redirected.
Its original intent was simply to create user feedback and create simple, console-based user interfaces (colored output).
Due to the prior inability to be captured or redirected, PowerShell version 5 made Write-Host
to the newly introduced information stream (number 6
), so since then it is possible to capture and redirect Write-Host
output.
Write-Error
is meant for writing non-terminating errors to the error stream (number 2
); conceptually, the error stream is the equivalent of stderr.
Write-Output
writes to the success [output] stream (number 1
), which is conceptually equivalent to stdout; it is the stream to write data (results) to.
Write-Output
is rarely needed due to PowerShell's implicit output feature:
Write-Output "Honey, I'm $HOME"
and "Honey, I'm $HOME"
are equivalent, with the latter not only being more concise, but also faster.You simply cannot get PowerShell to ommit those pesky newlines. There is no script or cmdlet that does this.
Of course Write-Host is absolute nonsense because you can't redirect/pipe from it! You simply have to write your own:
using System;
namespace WriteToStdout
{
class Program
{
static void Main(string[] args)
{
if (args != null)
{
Console.Write(string.Join(" ", args));
}
}
}
}
E.g.
PS C:\> writetostdout finally I can write to stdout like echo -n
finally I can write to stdout like echo -nPS C:\>