Hi I’m passing the following guid as a string parameter into PowerShell
90217784-164C-4E96-A117-CAFB6E440C6A
You must provide a value expression following the '-' operator.
At line:1 char:340
{90217784-164C-4E96-A117-CAFB6E440C6A}
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Unexpected token '164C-4E96-A117-CAFB6E440C6A' in expression or statement.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : ExpectedValueExpression
The PowerShell code works fine with all other GUIDs so far - It there any special combination of characters that would could this particular one to fail?
Hi yes thanks for your response I did pass quotes around the guid - this is actually called via a SSIS package. I don’t want to post the code as yet as so much of it contains Info that will need to be obfuscated. It has worked successfully with all values thus far, so I don’t think its a coding issue. Looks like something special relating to this particular guid is causing confusion with PowerShell.
I was hoping thst sone of you guru’s might recognise a particular character combination on the guid that coincidentally might also be of some significance in powershell. The guid is the same type as all others. Generated from a newid() command in sql server.
If this is not the case then I’m at a bit of a loss and will have to think of a way to cater around it. I will have a rethink and get back to you with the code if need be.
This is a syntax error, not an issue with your guid. Therefore, we can’t help with your syntax error unless we see the portion of code that is causing it. My guess is the same as Olaf’s, you have missing quotes. But that’s just a wild guess. The issue could be caused earlier in your code as well.
Can’t really help as much as we’d like if we can’t see your code. I’m willing to bet you can share it, or at least parts of it, enough for us to assist. If that much obfuscation needs done in this part of the function there’s probably other concerns.
It’s very likely a syntax/parsing issue. If you look at the error message, it’s thinking the first hypen is an operator, which means it doesn’t see that entire thing as a ‘string’ Typically without seeing code the best bet is, it’s not wrapped in quotes, as Olaf mentioned. You can get the same error if you simply copy/paste that string without quotes in VS code or a powershell terminal window. From the error, the powershell engine is parsing it as if the hyphen is a operator (minus operator) so that only happens if it doesn’t see the entire thing as a string. There’s not a special combination of characters that would cause it to fail to my knowledge. If it’s actually being sent as a string, it should be okay. If its an actual parameter that’s being sent though, and [String] is enforced, I don’t even think the quotes are necessary, at least from my testing. This is why we need to see exactly what you are doing so we can replicate it on our own systems and debug.
If you’re not able to provide the code sample, we won’t be able to assist sorry.
so here’s a quick example of what I mean. This is in PS5. Notice I didn’t even cast string to it in the param block and I am not using quotes when I provide it a value. Using Quotes is ok too. There’s something else going on and we need to see the code to help you, as something in the code is telling powershell to parse the first hypen as a operator.
Very plausible and actually what I thought with my first response since curly braces are special characters in powershell (which is why i mentioned the quotes), but I was basically pointing out that there’s a lot of ways to get things done and we can’t assume to know the exact problem. My example is showcasing that it’s possible to solve the issue a different way depending on the need. He also said he’s using quotes and it still wasn’t working, so without more info it’s difficult to provide a fix.
more or less, we need the code that creates the function/script and exactly how he’s passing it and also need to know the expectations/outcomes so we can best assist.
