Richard Siddaway's Blog

Last time I showed how to split folder paths to just leave the path – no filenames or drive information. What about the opposite task – joining and testing folder paths.

Here’s an example

$basepath = 'C:\Scripts'

$pathsTotest = 'Containers','HyperV', 'NanoServer', 'NoSuchFolder'

$pathsToTest | foreach { 
    $path = Join-Path -Path $basepath -ChildPath $psitem 
    Test-Path -Path $path 
 }

When you run this the paths to test are joined to the base path and then tested.

The output is

True 
True 
True 
False

which isn’t the most informative you’ll ever see.

The output can easily be made more friendly

$basepath = 'C:\Scripts'

$pathsTotest = 'Containers','HyperV', 'NanoServer', 'NoSuchFolder'

$pathsToTest | foreach { 
    $path = Join-Path -Path $basepath -ChildPath $psitem 
    
    $props = @{ 
      Path = $path 
      Found = Test-Path -Path $path 
    }

    New-Object -TypeName psobject -Property $props 
      
 }

Create an object for the output using the full path you’re testing and the result

The output looks like this

Path                     Found 
 ----                    ----- 
 C:\Scripts\Containers    True 
 C:\Scripts\HyperV        True 
 C:\Scripts\NanoServer    True 
 C:\Scripts\NoSuchFolder False

You could save the output as a CSV for later work if required

Lets say you have a bunch of files in nested folders but  you just want the folders  not the file or drive

Our files look like this

C:\Scripts\HyperV\Setup 
 C:\Scripts\HyperV\attachdisks.ps1 
C:\Scripts\HyperV\get-mountedvhdDrive.ps1 
 C:\Scripts\HyperV\invoke-CIMshutdown.ps1 
 C:\Scripts\HyperV\set-loopbackswitch.ps1 
 C:\Scripts\HyperV\Set-NestedVirtualisation.ps1 
 C:\Scripts\HyperV\set-realswitch.ps1 
 C:\Scripts\HyperV\Start-AllWindowsVMs.ps1 
C:\Scripts\HyperV\Stop-AllVMs.ps1 
 C:\Scripts\HyperV\Stop-Lab.ps1 
 C:\Scripts\HyperV\test-HotfixIpresence.ps1 
 C:\Scripts\HyperV\Setup\Copy-Updates.ps1 
 C:\Scripts\HyperV\Setup\Get-LicenseStatus.ps1 
 C:\Scripts\HyperV\Setup\Install-RollUp.ps1 
 C:\Scripts\HyperV\Setup\New-VirtualMachine.ps1 
 C:\Scripts\HyperV\Setup\SCsetup.ps1 
 C:\Scripts\HyperV\Setup\Set-VMconfig1.ps1 
 C:\Scripts\HyperV\Setup\Set-VMconfig2.ps1 
 C:\Scripts\HyperV\Setup\setup (2).ps1 
 C:\Scripts\HyperV\Setup\setup.ps1 
 C:\Scripts\HyperV\Setup\sysprep.txt

You can strip out the file names using Split-Path and the –Parent parameter

PS> Get-ChildItem  .\HyperV\ -Recurse  | foreach {Split-Path -Path $_.Fullname  -Parent } 
 C:\Scripts\HyperV 
 C:\Scripts\HyperV 
 C:\Scripts\HyperV 
 C:\Scripts\HyperV 
C:\Scripts\HyperV 
 C:\Scripts\HyperV 
 C:\Scripts\HyperV 
 C:\Scripts\HyperV 
 C:\Scripts\HyperV 
 C:\Scripts\HyperV 
 C:\Scripts\HyperV 
 C:\Scripts\HyperV\Setup 
 C:\Scripts\HyperV\Setup 
 C:\Scripts\HyperV\Setup 
 C:\Scripts\HyperV\Setup 
 C:\Scripts\HyperV\Setup 
 C:\Scripts\HyperV\Setup 
 C:\Scripts\HyperV\Setup 
 C:\Scripts\HyperV\Setup 
 C:\Scripts\HyperV\Setup 
 C:\Scripts\HyperV\Setup

Split-Path also has a –NoQualifier parameter that strips of the drive – unfortunately its in a different parameter set to –Parent BUT you can use a pipeline

PS> Get-ChildItem  .\HyperV\ -Recurse  | foreach {Split-Path -Path $_.Fullname  -Parent | Split-Path  -NoQualifier  } 
 \Scripts\HyperV 
 \Scripts\HyperV 
 \Scripts\HyperV 
 \Scripts\HyperV 
 \Scripts\HyperV 
 \Scripts\HyperV 
 \Scripts\HyperV 
 \Scripts\HyperV 
 \Scripts\HyperV 
 \Scripts\HyperV 
 \Scripts\HyperV 
 \Scripts\HyperV\Setup 
 \Scripts\HyperV\Setup 
 \Scripts\HyperV\Setup 
 \Scripts\HyperV\Setup 
 \Scripts\HyperV\Setup 
\Scripts\HyperV\Setup 
 \Scripts\HyperV\Setup 
 \Scripts\HyperV\Setup 
 \Scripts\HyperV\Setup 
 \Scripts\HyperV\Setup

If you just want the folders and don’t care about the files try

PS> Get-ChildItem  -Path .\  -Recurse -Directory | 
 where FullName -Like "*HyperV*" | 
foreach {Split-Path -Path $_.Fullname  -Parent | Split-Path  -NoQualifier  } 
 \Scripts 
 \Scripts\HyperV

Just recently I’ve found my self repeatedly working through a location, location pattern.

cd C:\test\ 
.\hello.ps1 
cd C:\Scripts\

The pattern consists of changing to another folder. Running some code and then changing back to the original folder – assuming you can remember it.

I then remembered the location cmdlets

PS> Get-Command *-Location | ft -a

CommandType Name          Version Source 
----------- ----          ------- ------ 
Cmdlet      Get-Location  3.1.0.0 Microsoft.PowerShell.Management 
Cmdlet      Pop-Location  3.1.0.0 Microsoft.PowerShell.Management 
Cmdlet      Push-Location 3.1.0.0 Microsoft.PowerShell.Management 
Cmdlet      Set-Location  3.1.0.0 Microsoft.PowerShell.Management

The 2 useful ones in this working pattern are Push-Location and Pop-Location

Push-Location adds the current location to the location stack and moves you to a new location if you supply a path

Pop-Location pulls the topmost location from the location stack and moves you to that location

The pattern then becomes

PS> Get-Location

Path 
---- 
C:\Scripts

PS> Push-Location -Path C:\test\ 
PS> Get-Location

Path 
---- 
C:\test

PS> .\hello.ps1 
Hello world! 
PS> Pop-Location

PS> Get-Location

Path 
---- 
C:\Scripts

Saves all that remembering stuff

A comment on yesterday’s post about passing parameters into a script block asked why I hadn’t mention $using

$using allows you to access a local variable in a scriptblock

BUT you need to be careful

PS> $proc = "power*"

Invoke-Command -ScriptBlock { 
   Get-Process -Name $using:proc 
 } 
 A Using variable cannot be retrieved. A Using variable can be used only with 
 Invoke-Command, Start-Job, or InlineScript in the script workflow. When it is 
 used with Invoke-Command, the Using variable is valid only if the script block 
 is invoked on a remote computer. 
 At line:4 char:4 
 +    Get-Process -Name $using:proc 
 +    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException 
    + FullyQualifiedErrorId : UsingWithoutInvokeCommand

What about the call operator?

PS> $proc = "power*"

& { 
   Get-Process -Name $using:proc 
 } 
 A Using variable cannot be retrieved. A Using variable can be used only with 
 Invoke-Command, Start-Job, or InlineScript in the script workflow. When it is 
 used with Invoke-Command, the Using variable is valid only if the script block 
 is invoked on a remote computer. 
 At line:4 char:4 
 +    Get-Process -Name $using:proc 
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException 
    + FullyQualifiedErrorId : UsingWithoutInvokeCommand

And in a job?

PS> $proc = "power*"

Start-Job -ScriptBlock { 
   Get-Process -Name $using:proc 
 }

Id     Name            PSJobTypeName   State         HasMoreData     Location  
 --     ----            -------------   -----         -----------     --------  
 3      Job3            BackgroundJob   Running       True            localhost

PS> Receive-Job -Id 3

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName          
 -------  ------    -----      -----     ------     --  -- -----------          
    510      26    42192      58004       0.55   9172   9 powershell           
    634      30    73112      90028       1.53  14680   9 powershell           
    955      68   161040     159956      12.23   4012   9 powershell_ise

You can’t use $using with the call operator and if you use it with Invoke-Command you have to be accessing a remote computer.

$using with InlineScript is for accessing variables defined elsewhere in the workflow

Passing parameters to a scriptblock seems to be an issue at the moment.

Consider a simple scriptblock

Invoke-Command -ScriptBlock {Get-Process}

How can you modify that to parameterise the processes that are returned.

Its a two step process. Add a parameter block to your script block and secondly pass the correct values to the scriptblock

Invoke-Command -ScriptBlock {
  param ($proc )
  Get-Process -Name $proc
} -ArgumentList "power*"

If you want to pass an array of values to the scriptblock you have 2 options. First abandon the named parameter

$p = ("power*", "win*")

Invoke-Command -ScriptBlock {
  
  Get-Process -Name $args
} -ArgumentList $p

if you use $args then all arguments are available through the array

Scriptblocks unravel the array of arguments so if you want named parameters then you need to force the scriptblock to accept an array by using the unary comma operator

$p = ("power*", "win*")

Invoke-Command -ScriptBlock {
  param ($proc )
   
  Get-Process -Name $proc
} -ArgumentList (,$p)