Day 2 can be located at http://powershell.com/cs/blogs/donjones/archive/2012/03/02/will-day-2.aspx
I guess Ive been running Powershell long enough that many of the cmdlets come fairly naturally. Before Powershell I was pretty heavy into cmd.exe, so, several of the commands outlined in section 2.3 - Managing files and folders - you know this! were familiar. When I started getting into Powershell I had to learn the syntactical difference Don points out. For example, dir /s is not a valid command in a default install of Powershell. As noted in the chapter, you can still run regular command line executables as you would since Powershell passes the command down the cmd.exe, but, doing so would more than likely leave someone missing the real power of this tool. Also, Dons trick with passing commands (and parameterized arguments) to regular executables (on page 17) is a great way to bypass funky parameterization issues that you may run into with Powershell. If youre in a hurry and getting weird argument issues, do this and save yourself some headaches.On thing Chapter 2 got me focused on is the best use of PSDrives. Having a little bit of development experience, PSDrives remind me of LINQ, a Microsoft initiative that cannot be found in Powershell. Both allow you to access a variety of data stores with little to no effort. Only in Powershell there virtually nothing required to access the stores other than use the provider names. Most of the Providers (not mentioned yet) make this happen almost seemlessly. What I got out of this chapter was an improvement I can make on some tricks I use. In the course of projects I work on I am regularly creating functions for quick access in Powershell. For instance, if I am working on a project whose files are on a drive pathed D:webfiles est I can create a new PSDrive called webtest: instead of having to point to this path any time I want to work on the data. Normally I create a function doing a cd (old cmd terminology or Set-Location in Powershell) to the path. Then, I alias the path. Instead of several lines of commands, I can just do a New-PSDrive to accomplish the same thing.Another thing Don emphasizes-which I wish I would have learned about earlier-was the Verb-Noun cmdlet naming pattern. The first time I started playing with Powershell (way back in 2006) I didnt get it at all. Having come from a cmd.exe/batch file background nothing made sense. A while later, when I revisited Powershell, realizing the action-on-object concept underlying the naming conventions got me over a big hurdle. As outlined on page 18, using basic commands (such as Get and Set) became more obvious and intuitive. If I want to act (get contents) on an object (directory) using Get-ChildItem I can have a clear idea of what will happen when I run that cmdlet. The further I have gotten into Powershell the more I have appreciate this self-describing characteristic of the language itself. Just by knowing what I want to do, thanks to the Verb-Noun patterning, I can guess what options (cmdlets) I might have available. To use Dons phrase, this is in and of itself an aspect of Powershell that I view as a discoverability feature. And a great one at that.While doing the exercises one thing that can be confusing is how to reference files in the current directory. The syntax goes back to UNIX in that all files have to have a path reference. In cmd.exe you can reference a file in the current directory without a directory reference. However, in Powershell, you cannot do this. A file must either have an absolute or a relative path. When I started doing the lab at the end of Chapter 2 I noticed this and recalled having trouble with it for a while. If you come from a background where this has been used it just a habit to get back into. If you have been a VBScript or cmd.exe person all along, this is good to pick up on early. Its true that a bit of dev background can make PowerShell a bit easier to pick up; its one reason I invited Will to join this little experiment. Looks like his Unix experience is serving him well, too. Not that you need any of that to learn PowerShell, but it does emphasize the shells philosophical consistency with whats come before. Microsoft didnt try to re-invent the wheel, here - just make a better one.
