Today's fun challenge on SPOT the TYPO will be a piece of a SharePoint deployment script!
Let's bring on the challenge!
SPOT the TYPO!
(line breaks added for readability; ignore them)
Still can't find it?
Maybe there's a problem with the image...let's try plain text!
stsadm.exe -o deploysolution -name MySolution.wsp –immediate -allowgacdeployment
Wait, I think I saw something!
Here's the image, enlarged:
I definitely saw something!
Now let me highlight the important bits. Enhance!
MYSTERY: why is this dash character wider?
Something is definitely fishy! Let's check out a hex dump and see what it says!
Hey, now that doesn't look like the standard ASCII character for a dash! That's not like a dash at all! In UTF-8 encoding (as this file is encoded), ASCII characters should look like ASCII characters! Right? Right!
Dude, where's my
It turns out, it's the endash, "–"--heretofore dubbed "the script ruiner." Read all about it (and I mean all about it) in this incredibly detailed article, about the endash. I'm serious, check it out.
OK, WE GET IT
As is always the case with these "why did my character magically become some other character" mysteries, we can safely blame Word AutoCorrect. When we're typing up technical documentation in Word: blame AutoCorrect. Even when we're typing in Outlook, where we think we're safe: we're not safe, Word AutoCorrect lurks in the shadows! It's hiding under that huge ribbon, waiting to pounce! Ha-ha, those three dots just became an ellipsis! You didn't even notice!
Let's say we're looking at a complex Microsoft Knowledgebase article, oh, say #934838. Let's just say. And let's say that on this article, there are lots and lots of commands just begging to be cut-and-pasted into your favorite text editor, Notepad. Notepad is your favorite text editor because you're not crazy enough to attempt to install another one on the production server. And when you paste this into Notepad, everything looks great on the standard Notepad monospace font. It's a monospace font, think about it.
And then you paste the text directly into the Command prompt, which spits out the generic stsadm error, which is hilarious, because they put the error at the TOP and immediately kick off a 5-page command listing, so you have to dig for the original error message. And yes, the error message says "Command line error." And you're studying, and studying, and you have no idea why this isn't working!
LET ME TELL YOU WHY IT ISN'T WORKING. Because when you zoom in, REALLY zoom in, you'll see that the dash character is exactly two pixels wider! And boy, let me tell you--those two pixels make all the difference! Get out your microscope!
Zoomed-in SharePoint art
If you look at the hyper-zoomed-in picture from above, it almost looks like some sort of awful abstract art. Noticing this, I thought--might as well go with it! Allow me to add a few touches here and there, maybe work with the interplay of light and form and structure, maybe add some tasteful emotion words...and give birth to the worst SharePoint-themed abstract art ever:
As with all true art, each person will take away something different from this piece.
I dare you, dear reader, to take on the challenge: can you create something worse? You can! You have it in you! Believe in yourself!
Tiny PowerShell footnote
There is a systematic way to find Unicode characters in your strings--just check the integer value of each character. Should be easy, right? I'd say so, yes:
Note I used the "%" shortcut instead of "foreach", and "?" instead of "where". Read it as: convert the string to a char array; for each character, convert it to an int; now filter these integers down to only those with a large (non-ASCII) value. The remaining ints are returned to the prompt, which displays them as best it can. There happens to be only one character today, which is the endash, "the script ruiner."
Anyway, the point is you can guarantee your string is ASCII if you make use of PowerShell's (.NET's) built-in Unicode support and write a simple script.