Why do such a thing? Well, if you’ve created your own aliases for commands and you try to give someone your ps1 script file, it will not run because they have not got the same aliases defined as you. Also, scripts that use fully-resolved names like “Get-ChildItem” are more readable for a newcomer to PowerShell than one that is using the unix-like “ls" alias for example. "Get-ChildItem" leads quite directly to the MSDN documentation, but "ls" might lead you anywhere. Before you publish a script online somewhere for the world to use, it’s important that you try to remove any aliases and replace them with the native command names.
Doing this kind of thing has been talked about before but it was always a very difficult thing to do with PowerShell v1.0, what with the lack of BNF documentation describing the grammar etc. Thankfully, it's a lot easier to do with PowerShell v2.0 (currently at release CTP2) because the team has exposed the Tokenizer for use in scripts. There's been suprisingly little use of it so far, so I figured I'd start the ball rolling with a series of articles based around it. So, let's look at an example script that uses aliases and put it through the meat grinder:
As you can see, it spits out the expanded script to the output stream. The informational messages are written to the host, so they won't interfere if you redirect the output to a file like: .\resolve-aliases.ps1 in.ps1 > out.ps1
Here's the Resolve-Aliases.ps1 script itself:
- #requires -version 2
- param ( $filename = $(throw "need filename!" ))
- $lines = $null
- $path = Resolve-Path $filename -ErrorAction 0
- if ( $path ) {
- $lines = Get-Content $path .path
- } else {
- Write-Warning "Could not find $filename"
- exit
- }
- # Initialize
- $parser = [system.management.automation.psparser]
- $errors = new-object system.management.automation.psparseerror[] 0
- do {
- $tokens = $parser : :tokenize ( $lines , [ref] $errors )
- $retokenize = $false
- if ( $errors .count -gt 0) {
- Write-Warning "$($errors.count) error(s) found in script."
- $errors
- exit
- }
- # look through tokens for commands
- $tokens | % {
- if ( $_ .Type -eq "Command" ) {
- $name = $_ .Content
- # is it an alias?
- # we use -literal here so '?' isn't treated as wildcard
- if ((!( $name -eq "." )) -and ( Test-Path -LiteralPath alias: $name )) {
- # gcm may return more than one match, so specify "alias"
- # filtering against name kludges the '?' alias/wildcard
- $command = gcm -CommandType alias $name | ? { $_ .name -eq $name }
- # resolve alias which may lead to another alias
- # so loop until we reach a non-alias
- do {
- $command = Get-Command $command .definition
- } while ( $command .CommandType -eq "Alias" )
- Write-Host -NoNewline "Resolved "
- Write-Host -NoNewline -ForegroundColor yellow $name
- write-host -nonewline " to "
- write-host -ForegroundColor green $command .name
- # Use a stringbuilder to replace the alias in the line
- # pointed to in the Token object. StringBuilder has a much
- # more precise Replace method than String. This allows us to
- # replace the token with 100% confidence.
- $sb = New-Object text.stringbuilder $lines [ $_ .startline - 1]
- $sb = $sb .replace( $name , $command .Name, $_ .startcolumn - 1, $_ .length)
- $lines [ $_ .startline - 1] = $sb .tostring()
- # now that we've replaced a token, the script needs to be reparsed
- # as offsets have changed on this line.
- $retokenize = $true
- # break out of pipeline, (not 'do' loop)
- continue;
- }
- }
- }
- } while ( $retokenize )
- Write-Host "" # blank line
- # output our modified script
- $lines
Of course, this requires PowerShell v2.0 CTP2. Next in the series, I'll give you a script to check your ps1 scripts for backwards compatibility against PowerShell 1.0. That should be handy for those naughty admins out there who despite all the warnings have installed v2 in production. ;-)
