detox icon indicating copy to clipboard operation
detox copied to clipboard

Detox not replacing 0x202F (narrow no-break space) on MacOS

Open germyparker opened this issue 10 months ago • 0 comments

As the title says, the 202F character (NNBSP) isn't being replaced with _ in MacOS. I've confirmed the character is in detox -- line 213 of unicode.tbl. When I take the exact same (problematic) file, rsync it to my Linux computer, confirm the character hasn't been altered (via vim -> ga), then detox it, the bad character is successfully replaced. But not in MacOS???

Some details, because who doesn't love details:

When you take a screenshot or screen recording using the default MacOS tool (Command + Shift + 3 or 5), the file is saved with the following filename:

Screen Recording 2024-04-24 at 12.22.20 PM.mov

Most of those "spaces" are in fact normal spaces, but that last one -- between the time and PM -- is the NNBSP. (Why do they do that? Because Apple. Why do we use Linux whenever possible? See previous response.)

╰─ echo "Screen Recording 2024-04-24 at 12.22.20 PM" | detox --inline
Screen_Recording_2024-04-24_at_12.22.20 PM

After doing some research, I can provide these additional -- tho not necessarily helpful -- details:

  • The NNBSP was in the MacOS screenshot filenames since at least January 4, 2024; however, that file also has regular spaces in the filename, so I clearly didn't run detox on it at that point, so I don't know whether it would have successfully changed the NNBSP.
  • I updated to detox v2 on April 10th, but I have files with this issue from April 4th that should have had detox run on them before that update -- I have a file organization script that includes detox; I can't 100% confirm that I ran the script between 4/4 and 4/10, but it's very likely. (I could probably find that info if it would help.)
  • I got this MacOS computer (from work! linux4lyfe) in mid-february. It has a M3 Max cpu (which is ARM-based). Previous to that, I was using an x86 MacOS computer. The Linux computers have always been x86. Previous to the new laptop, all my files were dancing between Linux and MacOS constantly, so info before that is unreliable.

If it helps, I'd be happy to perform any tests you might need, in case you don't have a MacOS computer around. I can probably test on a non-ARM MacOS computer if you'd like, I just need to steal my old computer back from my wife.

germyparker avatar Apr 24 '24 18:04 germyparker