alternatives to suppress output
Larry__Weiss
The following will destroy and recreate a subdirectory
if (Test-Path subdir) {rmdir subdir -Recurse}; mkdir subdir
but will produce output to the console:
PS C:> if (Test-Path subdir) {rmdir subdir -Recurse}; mkdir subdir
Directory: C:\Documents and Settings\Larry\My
Documents\WindowsPowerShell
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 6/15/2010 6:01 AM subdir
There are many ways to suppress the output to the console
if (Test-Path subdir) {rmdir subdir -Recurse}; mkdir subdir >$null
if (Test-Path subdir) {rmdir subdir -Recurse}; mkdir subdir | Out-Null
if (Test-Path subdir) {rmdir subdir -Recurse}; $null = mkdir subdir
if (Test-Path subdir) {rmdir subdir -Recurse}; [void] (mkdir subdir)
Are they all really the same thing, with regards to side-effects ?
Are there other ways to suppress the output?
Which technique to suppress console output is preferable?
- Larry
Bob Landau
and could change.
The all eat the output though
My preference is the first simple because its one that most people are
familar with. As a side note there is at least one more variation on what
you've said below using sub-expressions but works on multiple lines
$(
line 1
...
line n ) | Out-Null
I've used this in the past when I'm too lazy to find the source of some
unwanted output in a script.
If you are really interested look up Get-TraceSource/Trace-Command. You
won't find much documetation on how to interpret the results though.
bob
"Larry__Weiss" wrote:
> .
>
Larry__Weiss
Thanks.
I approach this from three points of view.
(1) effectiveness, including side-effects
(2) efficiency
(3) code style
In this case, there must not be much to say at this time about (1) and
(2), so (3) will be my focus.
I agree that
mkdir subdir >$null
is the one deemed most readable of those alternatives.
I do like the way that
$null = mkdir subdir
follows the pattern of how PowerShell usually prevents a statement from
contributing output to a pipeline, or a function's returned values.
- Larry
Larry__Weiss
Yes, I have dabbled with PowerShell tracing, but can't make much sense
of the details of the trace. I think I do get an overall "feel" about
what is going on, but nothing definitive.
- Larry
On 6/15/2010 10:19 AM, Bob Landau wrote:
> ...
stej
and imho they are interchangeable.
Considering efficiency (it it is about speed), scripts are interpreted
and PowerShell's main goal is not to be efficient, so I wouldn't
bother.
Some time ago I asked on StackOverflow if there is any coding style
for PowerShell. There was only one answer, but the user (I think
Richard Berg) presented only his coding style, not a general guide.
There are often many ways how to go to the destination and you can
select any of them. In this case there are four and it's up to you.
IMHO nobody will tell you what is the preffered way.
Larry__Weiss
The best coding style guidelines include rationale for each suggestion
so you can learn the pros and cons.
One specific guideline I'm trying to enforce on my own PowerShell code
is to use single quotes whenever possible, and reserve double quotes to
alert the reader of the code to expect expandable content in the string.
The important thing to me is
1) use a consistent style
2) when maintaining existing code use the same style as already exists
until you find the opportunity to refactor the entire module
- Larry
On 6/15/2010 5:05 PM, stej wrote:
> ...
> Some time ago I asked on StackOverflow if there is any coding style
> for PowerShell. There was only one answer, but the user (I think
> Richard Berg) presented only his coding style, not a general guide.
>
> There are often many ways how to go to the destination and you can
> select any of them. In this case there are four and it's up to you.
> IMHO nobody will tell you what is the preferred way.
>