
I was trying to set a string to a directory path and found when the combination of the characters \" comes up it seems to be interpreted as a token of some sort. For example:Code:
$TheFilePath ="F:\Images\"
Will give a Missing quotes or invalid expression error when it's run.
I tried a work around for it by establishing a slash character variable:Code:
#Since there is no To Char or Char function, I did it like this:
$SlashChar =GetCharAt("\A",0)
#So then I could do this:
$TheFilePath ="F:\Images"+SlashChar
Same error.
"F:"+'\'+"Images"+'\'
Ignore me. I see you tried that.
Thanks for the suggestion, unfortunately that doesn't work either. I don't think the scripting language will accept single quotes at all, but I'm not positive of that. Also, the first slash is accepted fine as in:
Code:
This works fine. It's only the \" combination that generates an error.
Might as well take the opportunity of this post to expound on work arounds. I'm using arrays to hold the file names and select one to work with as needed.
One work around was to do something like this:
Code:
Basically any letter or character combination after the last slash. Then add that to the file name, such as:
Code:
You add the A_ to the beginning of the file name (on the disk) for anything you are going to parametrically add to the basic file path in the script. You still use the file name without the A_ in the script itself (as shown above). Of course, it can be any character or any combination of characters, not just A_. Just so you don't end up with the \" combination anywhere.
Another work around is to put the whole file path and file name in the variables holding the file names in the script. But it is wasteful, and. worse yet, upsets my sensibilities.
For now I'm using the first work around and renaming the files themselves with the letter-underscore combination. That way I don't have to change all the variable entries that are holding the file names in the script when this problem is resolved. But I will have to rename all the file names on the disk files back to what they were. In the script all I need to do is get rid of the A_ in the $TheFilePath variable definition. Just one line of code. Changing the file names on the disk isn't a difficult job either as I use a great program called Rename Master. You can make changes to file names in an entire directory at once with it. It's amazing what all it can do. Often saved me a lot of work.
$slasher = &h92 or
$slasher = 0x92
Code:
$slasher = "\x92"
Thanks again for a good suggestion. In this case though, it just converts the expression into a number instead of a character. Being untyped variables in the script language, I can't readily coerce it into being a character. I tried using it directly in the path variable as well, but it just appended a number instead of a slash:
Code:
@JustinRatliff
An excellent suggestion. One of those "Why didn't I think of that" kind. Just adds one extra character to the list of names. I think that's what I will do. Come to think of it, when it comes time to get rid of the slash in the stored names in the script, I can just use the search and replace editing function to get rid of them all in an instant. If the bug is never fixed, well ... at least that works and doesn't upset my sensibilities (as much).:) Thanks again.
You may be right, but it's been my experience that anything goes as long as it's between quotation marks. Keywords, operators, reserved words, whatever. So I still think this a bug. The script help does leave a lot to be desired, so not being in there isn't particularly meaningful. The only way to find out Script behavior on many issues is just to try it and see what happens. I've been doing that as I go. Adding to the help file for my own reference. But, what the heck, it can even be fun trying to find ways around the little buggy critters. Just another good mental exercise.
I waited a few days to see if there was going to be any official response to thie problem, but I guess not. Anyway, it's time to close it out and give credit where credit is due. Thanks so much for your suggestion, it filled the bill for a good work-around.