Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

locked by voretaq7 Feb 27 '12 at 22:37

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

    
Sister question at Stack Overflow: stackoverflow.com/questions/893295 –  Peter Mortensen Mar 18 '10 at 10:23
    
Hidden features ought to be stuff that's NOT going to be in "Powershell for Dummys", but might be in a future O'Reilly "Powershell Annoyances" or "Powershell: The Forgotten Manual" ... –  Ryan Fisher Feb 10 '11 at 18:31
comments disabled on deleted / locked posts

7 Answers

Force Powershell functions to really return an array, even an empty array.

Due to the way the @() syntax is implemented, functions may not always return an array as expected, e.g. the following code will return a $null and NOT an empty array. If you are testing code with set-StrictMode -On set, you'll get an PropertyNotFoundStrict error instead when trying to reference the .count property:

function test
{
    #some code that might return none,one or multiple values
    $data = $null
    return @($data)
}
(test).count

Simply prepending a , to the @() will bypass the "syntactic sugar" and you'll have an actual array returned, even if it's empty:

function test2
{
    #some code that might return none,one or multiple values
    $data = $null
    return ,@($data)
}
(test2).count
share
    
Now, this is a proper " hidden feature". Can someone downvote the "accepted" answer by the OP himself. That answer is ridiculous. –  manojlds Aug 1 '11 at 21:05
add comment

Make your own custom functions and save them in your profile. You can build tons of useful functions without having to re-think it all every time a similar problem pops up.

Edit your profile:

PS C:\> notepad $profile
share
    
Try the "ise" command instead... Syntax coloring, debugging, etc. more nifty than notepad.exe and it's included with PowerShell v2. –  Ryan Fisher Feb 9 '11 at 18:07
add comment

Access any .net classes by using Add-Type -Assembly with the assembly name, or Add-Type -Path with the dll path, and then using syntax like [Namespace.Dotted.ClassName+NestedClass]::StaticMethod() to create a New-Object Namespace.Dotted.ClassName or invoke static methods/fields on types.

share
add comment

Save files using different encoding than UTF-16 in ISE.

The Powershell ISE defaults to saving all files as "Unicode Big Endian" (UTF-16) encoding. The following code will create a menu item in the ISE and assign a hotkey (default, Ctrl-Shift+E) to save the file in the current PowerShellISE tab using a specified encoding other than UTF-16. I set it to UTF-8, but you could use ASCII or something else if desired.


$iseProfile = $profile -replace '_profile','ISE_profile'
$addMenuCmdStr = '$psISE.CurrentPowerShellTab.AddOnsMenu.SubMenus.Add("_Save as UTF8",{$psIse.CurrentFile.Save([System.Text.Encoding]::UTF8)},"Ctrl+Shift+E")'
add-content $iseProfile -value $addMenuCmdStr 
ise

This trick is useful for avoiding certain issues with PowerShell scripts such as:

  • Subversion (possibly other CVS systems) adds .ps1 files to the repository as binary and not as plain text, won't allow you to "diff" your scripts because they are "binary", or generates an error that a file cannot be added because it is "binary mime-type". Changing the encoding to UTF-8 should allow your files to be added to the repository with svn:mime-type/text-plain and allows the diff functions to work.

  • Signing code using set-AuthenticodeSignature fails for some files and not others

  • Probably other cases were file content operations work for some files and not others, often for no apparent reason, but one symptom is that only files created with the ISE have the issue.

share
    
To be fair, though, treating text files in UTF-16 as binary files is a bug in Subversion. Yes, it makes life harder at times but ultimately it's not to blame on tools that choose a perfectly acceptable character encoding. –  Јοеу Feb 1 '11 at 21:54
    
Good point. File encoding defaults are not a bug in PowerShell or the ISE, so I'll change the 'hidden-feature' aspect to "saving files using different encoding", rather than fixing a "bug". It took DAYS to find this as my work-around for both Subversion and code-signing and I posted it heere as soon as I found, so I had a little "post-chase fever". ;-) –  Ryan Fisher Feb 10 '11 at 17:56
add comment

Splatting. You can define a bunch of arguments in a Hashtable, and then use it as the parameters of a function.

$sendMailParameters = @{
    To = 'someone@somebody.com'
    From  ='someone@somebody.com'
    Subject = 'Something'
    Body = 'Some stuff'
    BodyAsHtml = $true
}

Send-MailMessage @sendMailParameters
share
add comment
up vote 0 down vote accepted

Moving mine to an answer so I don't feel bad making this a commwiki.

Foreach loops:

PS C:\> foreach ($a in "a","b","c") { write $a }
a
b
c

Changedir to a UNC path:

PS C:\> cd \\kcws\c$
PS Microsoft.PowerShell.Core\FileSystem::\\kcws\c$>

Get running services:

PS C:> get-service | where {$_.status -eq "running"}

Status Name DisplayName
------ ---- -----------
Running AeLookupSvc Application Experience
Running Appinfo Application Information
Running AudioEndpointBu... Windows Audio Endpoint Builder
Running Audiosrv Windows Audio
[...]
share
    
Something like this ($OFS) will be more like a hidden feature. stackoverflow.com/questions/617369/powershell-joins/… –  Sung May 3 '09 at 2:20
3  
How are these "hidden features"? This is stuff in the first chapter of any book on powershell... –  Ryan Fisher Feb 10 '11 at 18:26
2  
Huh, foreach is a hidden feature!? –  kizzx2 Apr 1 '11 at 16:15
add comment

This is more of a non-obvious hassle, but I once wrote a script to produce a CSV file as input for an older executable, ofiller.exe, which is used with Checkpoint firewalls.

I was using output redirection: Script.ps1 > outfile.csv

My powershell-created CSV file didn't work, where my hand-written test CSV file worked fine, even though the two files diff'ed identically. Only when I looked at the size of the files did I realize it was a Unicode Vs ASCII problem; the powershell CSV was twice as large.

Piping my output to | Out-File -format ASCII -name outfile.csv instead of the cheap & cheerful STDOUT redirection solved the problem.

share
    
You can access the [console] object directly to change these defaults in your $profile if you want to. Take a look at the settings with this command: [console]::OutputEncoding | format-list * –  Ryan Fisher Oct 11 '11 at 19:45
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.