Troubleshooting a Script That Uses the TrimStart Method

 

Hey, Scripting Guy! Question

Hey, Scripting Guy! Greetings from an old VBScript guy. I have a problem with a Windows PowerShell script. It returns the unexpected result of "RANSFER" instead of the desired result of "\TRANSFER". One more thing: How can I use the TrimStart method to cut exactly what was given instead of doing it like it does? Here is the script:

$FullPath ="\\TVVVGXMFIL001D\IT-TEMP\MIHA\TRANSFER"
$PathToRemove ="\\TVVVGXMFIL001D\IT-TEMP\MIHA"
$FullPath.TrimStart($PathToRemove)

- MH

SpacerHey, Scripting Guy! Answer

Hi MH,

Cool question! I had to look this up myself. Here is the skinny on the TrimStart method.

The TrimStart method removes from the current string all leading characters that are in the trimChars parameter. The trim operation stops when a character that is not in trimChars is encountered. For example, if the current string is "123abc456xyz789" and trimChars contains the digits from '1' through '9', the TrimStart method returns "abc456xyz789".

The behavior of TrimStart is because of the way it is implemented in the .NET Framework; therefore, the Windows PowerShell team does not really have control of it. It is not, however a bug. It is just strange.

TrimChars is an array, not a simple string of characters. So when you have your path to remove, it is looking at an array of letters. In your full path string, the first letter that is not in your array is the letter R, so it trims from there. Here are the first two parts of your code. If you look at each path, the $PathToRemove variable already has the letter T in it, so when we see the T in front of the word Transfer, the T is also removed. So the first letter that is not part of the array that gets created from the $PathToRemove variable will be where the remainder of the string is found. In this example, the part that is left is Ransfer, and not Transfer as you were expecting:

$FullPath="\\TVVVGXMFIL001D\IT-TEMP\MIHA\TRANSFER"
$PathToRemove="\\TVVVGXMFIL001D\IT-TEMP\MIHA"

Here is how I would write what you are trying to do; I would use the Split-Path cmdlet as shown here:

PS C:\&gtp $FullPath="\\TVVVGXMFIL001D\IT-TEMP\MIHA\TRANSFER"
PS C:\> Split-Path $FullPath -Leaf
TRANSFER

Answer to your last question: It can't—that is just the way that it works.

By the way, this is for free: If you are missing instr, you can use the IndexOF method from the string class. You could then pair that with a substring. This is documented at http://www.microsoft.com/technet/scriptcenter/topics/winpsh/convert/instr.mspx.

 

How Do I Change Selected Files to Be Read-Only Files?

 

Hey, Scripting Guy! Question

Hey, Scripting Guy! I have just found this script: http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct04/hey1019.mspx. It is on the right track, but as usual I want something slightly different. In my case, I want the files I have selected already (normally between 1 and 20) located in a folder on the network to all become read-only files. Some may already be locked, so that's why I liked the checking loop rather than the toggling approach. Is this possible? Ideally the script should be on my C: drive and not in the individual folder next to the target files. I am using Windows XP Professional.- AH

SpacerHey, Scripting Guy! Answer

Hi AH,

this:
ReadOnly = 1
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFolder = objFSO.GetFolder("C:\fso")
Set colFiles = objFolder.Files
For Each objFile in colFiles
   If objfile.attributes And ReadOnly Then
        WScript.Echo objFile.name + " is already readonly"
   Else
       objFile.Attributes = objFile.Attributes Xor ReadOnly
   End if
Next
Top of pageTop of page

Troubleshooting the Enable Mailbox Command

 

Hey, Scripting Guy! Question

Hey, Scripting Guy! I am trying to run the following <formatting role="bold">enable mailbox</formatting> command on users who are not mailbox enabled. I then want to write the output to a file. This file is invoked by a .bat file. Here is the script:

$date = ((get-date).toString('MMM-dd-yyyy'))
$outputfile = "c:\scripts\" + $date + '.out'
get-date | Out-File $outputfile -append
get-user -organizationalUnit TestOU | 
where-object{$_.RecipientType -eq "User"} | 
Enable-Mailbox -Database "ORE\MailBox Database" | 
get-mailbox | s
elect name,windowsemailaddress,database |
Out-File $outputfile –append

However, I get an error returned in red text. When I launch the Exchange Management Shell and just copy and paste the commands, it works just fine and writes to my output file. Any idea about what's going wrong here?

- PJ

SpacerHey, Scripting Guy! Answer

Hi PJ,

When you open the Exchange Management Shell, the Exchange snap-in gets loaded. When you invoke the script via a .bat file, the Windows PowerShell console is loading, but is not loading the Exchange snap-in. What you need to do is to load the Exchange snap-ins within your script. Add the following line of code to the beginning of your script:

ADD-PSSnapin –name *exchange*

How Can I Run Scriptomatic 2.0 on Windows Vista?

 

Hey, Scripting Guy! Question

Hey, Scripting Guy! Thank you very much for the Scriptomatic 2.0. I must admit I was surprised to see such a fine tool coming from Microsoft. Unfortunately, I have a problem when I run it on Windows Vista. It gives me an error.- MP

SpacerHey, Scripting Guy! Answer

Hi MP,

Because of the way Scriptomatic 2.0 enumerates the WMI namespaces, it must be launched with administrator rights on Windows Vista. And because it is an HTA, it is not aware of the need for administrator rights. This causes Scriptomatic 2.0 to fail, rather than bringing up the UAC dialogue box to request admin rights. To run Scriptomatic 2.0 on Windows Vista, you need to first create a shortcut to the command prompt. Edit the shortcut so that it will run as an administrator. This is due to the fact that an .HTA file is not associated with the runas command. For that matter, neither is the .vbs file. When you have your administrator command prompt, you need to paste the path to Scriptomatic 2.0, or type the path to Scriptomatic 2.0 at the command prompt. When you have done this, you can launch Scriptomatic 2.0 in a normal fashion (if any of this stuff is normal). Going forward, you may want to actually edit the path of the elevated command prompt so that it actually launches Scriptomatic 2.0. PowerShell Scriptomatic is written in C# and uses an embedded manifest, which tells it that it needs to have administrator rights. It therefore will prompt for administrator rights when it is run on Windows Vista.

 

Ed Wilson and Craig Liebendorfer, Scripting Guys