Converting some dot sourced profile scripts to regular scripts

Topics: Developer Forum
Coordinator
Feb 18, 2007 at 11:35 AM
Inspired by this blog post: http://blogs.msdn.com/jmanning/archive/2007/02/14/why-share-able-functions-shouldn-t-be-in-your-powershell-profile.aspx and the fact that PoSH+PSCX is taking about 4-5 seconds to load on my 3 GHz PC, I'm thinking that we need move a number of functions out of profile into executable scripts. I propose that we create a scripts dir and add that to the path on install (perhaps as an option). There are a few functions that I can think of that I would like to keep dot-sourced - common ones like cd.ps1 and TabExpansion. Thoughts? Anyone else seeing this slow down in profile loading?
Developer
Feb 18, 2007 at 4:26 PM
The startup time is not so bad on my (far less powerful) tablet pc. However, it's not a bad idea. I wouldn't touch the machine Path variable however. I think better solution would be to Add-PathVariable "$Env:PscxHome\Scripts" to our Profile.ps1.
BTW, what about changing the profile installer to create a profile which would call our profile first, and then the original user-specific profile (if it exists)? That would allow installing all our stuff, while keeping any existing customizations the user might have.
Coordinator
Feb 18, 2007 at 7:10 PM
That sounds reasonable to me and yeah, using Add-PathVariable is definitely a better idea. I'm going to create a Scripts dir then and start converting dot-sourced functions to scripts.
Developer
Feb 19, 2007 at 3:03 PM
I think we should dot-source the Environment.VisualStudio2005.ps1 by default. It checks for Visual Studio presence, and does nothing when not installed. Also, remember we are going to call the shared profile in program files, which non-administrators cannot edit. We have the same problem with transcription and other things. Perhaps we should divide the profile into a "mandatory" file stored in program files, and a customization profile stored in MyDocs\WindowsPowerShell.
Coordinator
Feb 19, 2007 at 6:58 PM
OK putting back the VS2005 dot source sounds good since it is a no-op if you don't have it. What if we install the PSCX profile into their ProfileDir like we do today but maybe call it PscxProfile.ps1 and dot source it from their original profile? Of course, if they don't have a profile at all then I would be tempted to just install it as the non-host specific base profile (profile.ps1) like we do in 1.0. If we put it in their profile dir then at least they could more easily tweak it. Just thinking out loud here. I'm not set on any particular solution.
Developer
Feb 19, 2007 at 10:08 PM
It's already back there...I don't think messing with the user files is a good idea. You'd have to parse the file at least for presence of the param(xxx) statement. And uninstallation would be even more fragile.
I'd prefer renaming the existing profile to PscxUserProfile.ps1 (or something else?), and dot-sourcing it from our profile.
BTW, how do users who didn't install PSCX get our profile? How about putting the "core" functionality into the machine-wide profile (dot-sourcing the original), and copy the default customizations to per-user files?
Developer
Feb 20, 2007 at 2:28 AM
I made few changes to the profile. Could you review them? It's still in one file though...
Coordinator
Feb 20, 2007 at 2:40 AM
Looking. I do notice that you keep putting back in FileSystem.ps1 even though it has been moved to Scripts and renamed Get-DiskUsage.ps1. :-)
Developer
Feb 20, 2007 at 2:48 AM
yeah, I did it, but it's fixed already. I hope:)
Coordinator
Feb 20, 2007 at 3:04 AM
Hey I'm merging one of my changesets to trunk and I'm finding this in profile.ps1

else
{
	Update-FormatData
	Update-TypeData
}

Is that supposed to be there in both branches?
Developer
Feb 20, 2007 at 3:12 AM
This is supposed to be only in the "else" (when reloading) branch. It reloads all currently loaded type/format data.
Coordinator
Feb 20, 2007 at 3:54 AM
OK I merged my last set of changes to trunk. This was a bit tricky since you and I have been working on some of the same files. If I biffed it, let me know.
Developer
Feb 20, 2007 at 4:03 AM
one long-removed line returned somehow to the trunk\PscxSnapin.csproj and broke the xml structure. but that was probably my fault again :)
Coordinator
Feb 20, 2007 at 4:20 AM
Doh! Are you fixing that?
Developer
Feb 20, 2007 at 5:17 AM
Edited Feb 20, 2007 at 5:18 AM
yes, it should be ok now