I was just reading Steve Murawski’s latest blog post which contains a script called ConvertTo-Function that allows you to generate a function from a script file. The intent is to allow you to have scripts you don’t call as often, and therefore don’t load into your profile, but when you need them you can use this script to easily generate functions that wrap them so that you don’t need to think about the path beyond the initial call to the ConvertTo-Function script. That’s one way to facilitate this, but I have something I use quite commonly in my own environment that works much better for me for this scenario: aliases.
Aliases can reference a path to a script file.
This capability is often overlooked because aliases are most commonly used and thought of as terse command names. Using them to reference a path to a script file is quite useful because it allows you to keep all of your scripts, complete or in development, in a common location. You can control which ones are loaded in your profile by only creating aliases for those scripts. Alternatively, for scripts that you really don’t use very often, you could have a function in your profile to create the aliases to those scripts on an as needed basis (which sounds a little like the Add-Module capabilities in PowerShell v2). In either case, using aliases to reference script files is very handy because you don’t need to worry about whether the scripts you want to invoke are in a folder in your path environment variable or not. You simply need to create an alias to the full path and then you can use that alias to invoke your script.
For example, assuming you had a script with the path C:\MyScripts\Miscellaneous\Do-Something.ps1, you could invoke it using the absolute or relative path, or if C:\MyScripts\Miscellaneous happened to be in your path environment variable you could simply invoke it using the Do-Something command. But if you don’t have your script path in your path environment variable and/or you don’t want to change that variable, aliases give you the same capability on a temporary basis for your current PowerShell session (and only in your current scope by default if you want it really temporary). Using our example script path, all you would have to do is create a new alias with this command:
New-Alias Do-Something C:\MyScripts\Miscellaneous\Do-Something.ps1
That allows you to invoke your script any time you want to by simply using the Do-Something alias, as long as it is created and visible in the current scope.
Kirk out.
| Share this post: |  |
 |
 |
 |
 |
 |
 |
 |
 |
Poshoholic 
[…] Munro (@poshoholic) pointed out that aliases (and expands on it in this blog post) might be an easier way to go. That would definitely be an […]
The only problem I have with this technique is maintenance. I like to just toss all my scripts into a folder which is in my $env:path, or, toss functions into a series of library files which are dot-sourced automatically in my profile.
There isn’t any more maintenance with this technique. Well, sure, if you compare it to using a folder in your path variable, then it is a little more work. But when compared to using a series of library files, you can still create the library file which creates the aliases to your scripts and then dot source those files.
The biggest benefit I have found for me with this method is that it allows me to make modifications to functions (something that I do *a lot*) and get those changes immediately in PowerShell without needing to dot source the file. Again, if I had a scripts folder in my path this wouldn’t be necessary, but I’ve broken my script library up into subfolders and don’t want to have to modify my path each time I add a new folder to that script library.
Lastly, this works well when transferring scripts to other machines where PowerShell is installed because you can set up a base path and then build your relative script paths from that, move to a new machine, make one change if necessary (the base path), and then you can use your scripts there. For some reason this is an easier thought process to me than worrying about the path environment variable.
Anyhow, as with everything PowerShell, this isn’t the single best method by any means. It’s simply the one I’ve adopted because I found it works best for me.
Kirk out.