If there is a Unicode “narrow no-break space” (8239) in a string, and you use keystroke to type that string somewhere (tested in Terminal and TextEdit, so probably anywhere), that character gets replaced by the character “a”.
Here is sample code to replicate this:
set myString to "Screen Recording 2025-12-16 at 5.54.04 PM.mov"
tell application "TextEdit"
activate
make new document
delay 0.5
end tell
-- Type in the string:
tell application "System Events"
keystroke myString
delay 0.5
end tell
When I run this, the end of the file name is “5.54.04aPM.mov” (notice the extraneous “a”), instead of “5.54.04 PM.mov”.
That’s because apparently macOS saves the “time” in the names of screen shots and screen recordings using a non-breaking space before the AM/PM.
Anyone know why keystroke is unable to type that perfectly-valid-if-sneaky Unicode character?
I can set the clipboard and then paste, but I’d love to avoid modifying the clipboard, if possible.
That has been around since at least Sonoma. Looks like the forum ate the NNBSP in your sample script, by the way.
I think it was put in there to prevent a line break between the time and “AM/PM”, but obviously something didn’t get the message. As far as I can tell, it only happens with keystroke and not writing as «class utf8».
I was wondering if there might be a non-breaking space between elements (or before the ‘PM’) in the locale time settings.
You could always substitute it with a space as a workaround.
set mys to "Screen Recording 2025-12-16 at 5.54.04 PM.mov"
set text item delimiters to {space, character id 160}
set mys to text items of mys as text
And yeah, the forum does swap in a regular space.
You can use the html entity, ie but it is treated as literal text inside the code block.
Screen Recording 2025-12-16 at 5.54.04 PM.mov
In regular text or inside a block quote, you can enter the entity but the forum converts it to a space. These two entries are identical to the one above.
The character(s) in keystroke’s text parameter have to be in the software “keyboard” you’re currently using, otherwise they can’t be recognised and converted to the corresponding key press(es). Unrecognised characters get the equivalent of key code 0, which is an “a” on many keyboards.
Here is a workaround for the narrow no-break space being converted to ‘a’ when used in a keystroke.
set s to "Screenshot 2025-12-17 at 6.56.29 AM.png"
set out to (do shell script "sed 's/\\xE2\\x80\\xAF/ /g' <<<" & s's quoted form)
tell application "System Events"
keystroke return
keystroke out
end tell
Thank you all for the feedback on this.
The workaround suggested for just replacing the NBSP character with a normal space before typing won’t work, since I’m trying to type out a (longer) command that includes the path to an actual existing file.
My options seem to be:
a. Try the workaround hinted at by @Mockman of changing the way the system names screen-recordings, but I don’t know what other unintended side effects that would cause.
b. Rename the file before working with it, to replace that NBSP with a normal space.
c. Don’t use keystroke, since @Nigel_Garvey pointed out it just cannot handle that character, and instead just paste the command into the Terminal prompt. Not ideal, since I dislike modifying the clipboard when possible, but acceptable for what I’m doing here. So, I went with this option, and it works. And, I did a simplistic clipboard restore that would work for any text clipboard object.
I also thought about option b, but that could lead to future confusion when the screen-recordings that I’ve modified this way follow an invisibly different naming convention than those that I haven’t modified.