-Path commands

Topics: Developer Forum
Developer
Apr 5, 2007 at 5:01 AM
Edited Apr 5, 2007 at 5:11 AM
I'm checking in a script file I'd like to get some review/discussion on. It's inspired by an old W2K resource kit tool named Pathman.exe. This tool gave you a command-line interface to adjust the persistant "Path" environment variable stored in the registry. I recognize there's some overlap with PSCX 1.1's Add-PathVariable command, but I think you'll see there's a lot more to my functions.

I created a developer directory for myself and dropped it in
PowerShellCx/Branches/Developer/BurtHarris/Scripts/pathFunctions.ps1

To avoid polluting the namespace with internals, the externally-visible functions are explicitly declared as global:, so you don't need to .src it, just execute the script. It then defines Get-Path, Set-Path, Add-Path, and Remove-Path. I don't see existing scripts using this technique. Comments?

I'm not sure how you're doing documentation on exposed functions or cmdlets. Point me in the right direction and I'll write something up on them. Here are a few notes:

Scope: the -machine and -user switches allow operation on the registry-based persistant environment variables, while leaving them both off modifies the current process environment. The -name argument defaults to "PATH", but can be supplied for other purposes.

Formatting: Get-Path splits the path string on semicolons, and expands and short-path versions into long paths for display. Conversely, Set-Path converts long paths back into short-path format, keeping the environment variable compact. (These behaviors were orginally more important as 16-bit tools didn't understand long filenames.) The -LongPath and -ShortPath switches allow overriding this behavior.

Warnings: The commands address some common trouble-spots, for example checking for path validity of paths, and eliminating duplicates, generating warning-stream output to keep you informed. If your existing path has problems, invoking "add-path" with no arguments (or with -machine or -user) will clean it up.


Coordinator
Apr 8, 2007 at 12:55 AM
It seems that your Add-Path function is a superset of the Add-PathVariable. The thing is, with the mutually exclusive -machine/-user/-process (implied), it seems a cmdlet could handle this better via multiple ParameterSets (Process, User, Machine). In general, I'd rather see PSCX doing cmdlets than scripts where possible. Although I think general purpose (non-domain specific) scripts are OK.

I could also see wanting to use this functionality to get/set general (ie not path specific) environment variables at different levels (machine/user/process). What if you created a couple of cmdlets: Get-EnvironmentVariable and Set-EnvironmentVariable that acted as a cmdlet wrapper around environment::Get/SetEnvironmentVariable. In this scenario I don't think I would automatically try to split the env var value on ';'.

Then we could have the Add-Path and Remove-Path functions use those cmdlets to do their work? We could replace the Add-PathVariable function in Profile\GenericFunctions with these two functions. Although you should look at the Add-PathVariable to make sure we don't lose functionality. One thing I'm trying to be consistent on is having functions/scripts throw errors when a required parameter hasn't been provided.
Developer
Apr 9, 2007 at 6:46 PM
Thanks for the feedback Keith. I've verified that my Add-Path is a functional superset of Add-PathVariable, though the order of arguments isn't the same, so they are not upwards compatable. I chose to put the -Name parameter after the value(s) to be appended since it's got a meaningful default.

I find your comment about preferring CmdLets vs. Scripts interesting, and would like to understand your thoughts on the subject better. I've designed the scripts to be as CmdLet like as possible. One advantage I can see to using a compiled CmdLet is that it clarifies the situation about documentation, but I've got to beleive there's a reasonable way to address documenting scripts in a CmdLet like way.