alternatives to suppress output

838 views
Skip to first unread message

Larry__Weiss

unread,
Jun 15, 2010, 7:13:16 AM6/15/10
to

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

unread,
Jun 15, 2010, 11:19:11 AM6/15/10
to
For the most part these are implementation details that are not documented
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

unread,
Jun 15, 2010, 12:24:49 PM6/15/10
to

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

unread,
Jun 15, 2010, 12:44:59 PM6/15/10
to

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

unread,
Jun 15, 2010, 6:05:22 PM6/15/10
to
I'm not aware about any side-effects. All the options do its job well
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

unread,
Jun 15, 2010, 6:30:04 PM6/15/10
to

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.
>

Reply all
Reply to author
Forward
0 new messages