When I run the following relevance, it is returning a %a0 in the middle of the path. How can it handle this value? Evidently, what looks like a space in the path is not.
("del /q %22" & it & "%22") of (pathnames of it) of ((find files "*.url" of ((descendant folders of it; it) of folders "favorites" of folders of folder "C:\users")) whose (exists (following texts of firsts "=" of variables of it) whose (it as lowercase contains "http1.xxx.zzz.com" OR it as lowercase contains "http2.xxx.zzz.com")))
Output:
del /q "C:\users\mbartosh\favorites\Task%a0Details.url"
Took me a little bit of digging. That code is not within the ASCII table; but, according to http://unicode-table.com/en/#00A0, that is UNICODE for “No-Break White Space” which might make sense.
Since you’re in Favorites, it may be that the website that was bookmarked had this character in its title. I think it’s a bit odd that BigFix didn’t recreate the encoding when you wrote it out to the file though.
%A0 is the Windows-1252 non breaking space as well so you could add a percent decode it in the del form but I’m 100 percent sure that will work either
Is that output appearing in the Fixlet Debugger, or is the literal string %0a included as text in a createfile/appendfile output? I’ve seen instances where the debugger showed output as the string %0d%0a, while the created file had the correct CR/LF characters.
The FixletDebugger has to always percent encode control characters as they won’t display well otherwise. But %A0 isn’t a control character so if you turn off the percent decoding in the preferences it should show up as a space.