Remove-Item ri in Visual C#

Generator Code 39 Full ASCII in Visual C# Remove-Item ri

Table 10.1 The core cmdlets for working with files and directories (continued) Cmdlet name Mkdir Canonica cmd l alias command md UNIX sh Description command mkdir Mkdir is implemented as a function in PowerShell so that users can create directories without having to specify type directory. Send the contents of a file to the output stream. Set the contents of a file. UNIX and cmd.exe have no equivalent. Redirection is used instead. The difference between Set-Content and Out-File is discussed later in this chapter.

and you ll receive detailed help on the cmdlets, their parameters, and some simple examples of how to use them. In the next few sections, we ll look at some more sophisticated applications of these cmdlets, including how to deal with binary data. In traditional shell environments, binary data either required specialized commands or forced us to create new executables in a language such as C, because the basic shell model couldn t cope with binary data. We ll see how PowerShell can work directly with binary data. But first, let s take a minute to look at the PowerShell drive abstraction to simplify working with paths. 10.2.1 Working with PSDrives One useful aspect of the PowerShell provider feature is the ability to create your own drives. To keep people from mixing up the PowerShell drives with the system drives, we call these PSDrives. A common reason for creating a PSDrive is to create a short path for getting at a system resource. For example, it might be convenient to have a docs: drive that points to our document directory. We can create this using the New-PSDrive cmdlet:

PS (1) > new-psdrive -name docs -PSProvider filesystem ` >> -Root (resolve-path ~/*documents) >> Name ---docs Provider -------FileSystem Root ---C:\Documents and Settings\brucep Current Location --------

PS (2) > cd docs:

then use pwd (an alias for Get-Location) to see where we are:

PS (3) > pwd Path ---docs:\

We are, at least according to PowerShell, in the docs: drive. Let s create a file here:

Next, try to use cmd.exe to display it (we ll get to why we re doing this in a second):

PS (5) > cmd /c type junk.txt Hello there!

Well, that works fine. Display it using Get-Content with the fully qualified path, including the docs: drive.

PS (6) > get-content docs:/junk.txt Hello there!

it fails! This is because non-PowerShell applications don t understand the PowerShell drive fiction. Do you remember the earlier example, where we did a cd to the location first, that it did work This is because when we re in that drive, the system automatically sets the current directory properly to the physical path for the child process. This is why using relative paths from cmd.exe works. However, when we pass in a PowerShell path, it fails. There is another workaround for this besides doing a cd. You can use the Resolve-Path cmdlet to get the ProviderPath. This cmdlet takes the PowerShell logical path and translates it into the provider s native physical path. This means that it s the real file system path that non-PowerShell utilities can understand. We ll use this to pass the real path to cmd.exe:

PS (7) > cmd /c type (resolve-path docs:/junk.txt).ProviderPath Hello there!

This time, it works. This is an area where we need to be careful and think about how things should work with non-PowerShell applications. If we wanted to open a file with notepad.exe in the doc: directory, we d have to do the same thing we did for cmd.exe and resolve the path first:

If you frequently use notepad then you can create a function in your profile:

function notepad { $args | %{ notepad.exe (resolve-path $_)/ProviderPath }

You could even create a function to launch an arbitrary executable:

function run-exe { $cmd, $files = $args $cmd = (resolve-path $path).ProviderPath $file | %{ & $cmd (resolve-path $_).ProviderPath } }

This function resolves both the file to edit and the command to run. This means that you can use a PowerShell drive to map a command path to execute. 10.2.2 Working with paths that contain wildcards Another great feature of the PowerShell provider infrastructure is universal support for wildcards (see chapter 4 for details on wildcard patterns). We can use wildcards any place we can navigate to, even in places such as the alias: drive. For example, say you want to find all of the aliases that begin with gc . You can do this with wildcards in the alias provider.

PS (1) > dir alias:gc* CommandType ----------Alias Alias Alias Name ---gc gci gcm Definition ---------Get-Content Get-ChildItem Get-Command

We see that there are three of them. We might all agree that this is a great feature, but there is a downside. What happens when you want to access a path that contains one of the wildcard meta-characters: , * , [ and ] . In the Windows filesystem, * and aren t a problem because we can t use these characters in a file or directory name. But we can use [ and ] . In fact, they are used quite a bit for temporary Internet files. Working with files whose names contain [ or ] can be quite a challenge because of the way wildcards and quoting (see chapter 3) work. Square brackets are used a lot in filenames in browser caches to avoid collisions by numbering the files. Let s run some experiments on some of the files in the IE cache.