Guess I must be guilty for mixing up the control characters complication into already confusing unicode matters
Ed Dyreen wrote:
aGerman, why does it work with you and not for me
Short answer, and at the risk of repeating myself, but do _not_ use 'dir /b' in "for /f" loops anywhere near unicode.
Long answer: there are two characters which echo as "◄" in the console. One is the proper U+25C4 "left pointing pointer", per the unicode definition. The second one is U+0011 (or Ctrl-Q) which "happens" to display the same glyph by DOS/OEM legacy. The two characters are not the same, for example the U+25C4 is valid in pathnames while U+0011 is not.
A plain "for" loop returns the correct (unicode) filename from disk, which uses U+25C4. A "for /f" loop with 'dir /b' returns the remapped U+0011 character, instead. As good as that might look on screen, but the two don't match, which causes the "if exist" to not find the file and fail. Step by step below, assuming the Special◄.CMD file exists already...
Active code page: 437
C:\tmp>dir /b special*.cmd
C:\tmp>for %a in (special*.cmd) do @if exist %a (echo %a) else echo ???
C:\tmp>for /f %a in ('dir /b special*.cmd') do @if exist %a (echo %a) else echo ???
Now, to prove the 2nd point about the difference between U+25C4 vs. U+0011, run the following...
C:\tmp>for %a in (special*.cmd) do @set u25c4=%a
C:\tmp>for /f %a in ('dir /b special*.cmd') do @set u0011=%a
C:\tmp>cmd /u /c echo %u25c4:~7,1%>u25c4.txt
C:\tmp>cmd /u /c echo %u0011:~7,1%>u0011.txt
Then open the two .txt files in a hex viewer, and you'll notice that the first one carries character 0x25C4 (= bytes C4 25) while the second one has 0x0011, instead.