Working with the new Monad beta — getting settled in

As I mentioned earlier, we posted a new MSH beta to BetaPlace.  It’s a lot more polished than the one we posted 9 months ago, so I’ll be working with that version from now on.  The articles so far haven’t delved very deeply into code just yet (how fortunate!) so there aren’t many breaking changes we need to comply with.  However, there have been  few — so let’s go over them.


 


First, you’ll notice that we’ve significantly timmed down the default profile.  Much of the functionality was rolled into the engine, but a lot of it was simply code that very few people use.  Our journey so far has used a few of them, though.  For example, we used the “$MyDocuments” variable to help us load (dot-source) our custom profile.  However, we’re in good shape.  Even if you put tons of code in your custom profile, it’s in a separate file and will not be affected by changes to the default profile.  So, let’s fix that. 


 


First, verify that you have the current profile.  It should be about 66 lines.  



MSH D:\Lee\MSH >(get-content profile.msh).Count


66



If you see over 300, then that’s the old profile.  If you’ve still got the old profile, then you should really start with a clean slate.  Uninstall “Microsoft Command Shell Preview,” uninstall “Windows Command Shell Preview,” and delete the old profile.  Then, reinstall “Microsoft Command Shell Preview.”


 


Now, open the profile with your text editor of choice.  Re-add the $MyDocuments variable, and re-add the custom profile loading:





    }


}


 


$myDocuments = [Environment]::GetFolderPath(“MyDocuments”)


. (combine-path $myDocuments “MSH\profile-custom.msh”)



Save it, and reload your shell. 


 


If you liked the $profile variable, you might want to add that to your profile-custom.msh:




$profile = combine-path $myDocuments “MSH\profile-custom.msh”



If you aliased ‘cls’ to ‘clear-host,’ the default profile does that for you now.  Feel free to remove it from profile-custom.msh.  All told, this is my profile-custom.msh, as it stands right now. 




## profile-custom.msh


## Stores customizations to the default profile.


 


$profile = combine-path $myDocuments “MSH\profile-custom.msh”


$tools = combine-path $myDocuments “tools”


 


function prompt


{


   $currentDirectory = get-location


   “MSH $currentDirectory >”


}



Notice that I made the prompt function a little more readable, by temporarily storing the current location in a variable.  It will soon get ungainly should we try to stuff it all in a single line.  Also, I’ve added a variable to hold my tools directory.  My tools directory holds scripts that I’ve written, and other generally-useful utility programs.  You’ll want to add it to your path, so you have 2 options:


 


1) Use System Properties | Advanced | Environment Variables.  Create Path if it doesn’t exist.  If it does exist, append the value of $tools to it.


2) Do it from a MSH prompt:




MSH C:\Temp >$newPath = $tools


MSH C:\Temp >if((get-property HKCU:\Environment).Path)


>> { $newPath = (get-property HKCU:\Environment).Path + “;” + $newPath }


>> set-property -Path HKCU:\Environment -Property Path -Value $newPath


>> 


MSH C:\Temp >(get-property HKCU:\Environment).Path


d:\lee\tools



Now, restart your MSH shell.  Your $tools directory is now part of your path.  If you haven’t created the directory already, now is a good time to do so:




MSH C:\Temp >md $tools



As we create custom scripts, we’ll place them in $tools to allow us to run them from wherever we like.


 

[Edit: Monad has now been renamed to Windows PowerShell. This script or discussion may require slight adjustments before it applies directly to newer builds.]

4 Responses to “Working with the new Monad beta — getting settled in”

  1. Keith J. Farmer writes:

    Is C:\Documents…\username\MSH, on the installs I’ve done, ends up being in username’s My Documents folder (whereever that may be).

    I was curious about the "&" block that seems to cycle through the alphabet. I’m assuming the logic of it is that you create a lambda using the braces, then execute it with &. Would it work if you just dumped the contents of the block directly within profile.msh?

    ie
    foo
    instead of
    & { foo }
    ?

  2. Keith J. Farmer writes:

    So I was trying to figure out a way to manage the loading of .msh scripts from a standard directory. Essentially, I had the following defined in profile.msh:

    function global:load-script
    {
    $local:path = combine-path $MshScriptsDirectory $Args[0]

    echo "Loading $local:path…"

    . ($local:path)
    }

    and in my dot-sourced profile.custom, I had:

    load-script colorfuncs.msh
    load-script join-object.msh

    join-object.msh is your join-object script, wrapped in function join-object. After loading MSH, join-object is available. However, colorfuncs.msh also contains two functions:

    # color functions loader

    function reload-colorFunctions
    {
    echo "loading color functions"

    load-script MshColorFunctions.msh
    $global:MshLoaderColorFunctions = $true
    }

    function load-colorFunctions
    {
    if (!$MshLoaderColorFunctions)
    {
    reload-colorFunctions
    }
    }

    .. both of which give a not-recognized error when I attempt to call them.

    Yet if I dot-source colorfuncs.msh directly, they work.

    It seems to be an inability to programmatically dot-source into the global namespace. Is this a correct interpretation? Why would my prompt and join-object be properly loaded despite this?

  3. Lee Holmes writes:

    Keith: Regarding your first question, the function is a succinct way to create convenience functions that allow you to type "C:" and "D:" from the command-line, rather than "set-location c:" To see what the function does, try this: "dir function:"

    As for your second question, are you ever actually calling ‘load-colorFunctions’ ?

    Lee

  4. Keith J. Farmer writes:

    yes.. in my prompt. if you wish, I can zip up my MSH and email it to you.

Leave a Reply