Conversation

Notices

1. Embed this notice
   7666 (7666@comp.lain.la)'s status on Saturday, 05-Apr-2025 02:40:16 JST 7666

   in reply to

   • 7666
   this is how i know y'all ain't paying attention. this shit DON'T WORK
   
   here's why: say i enter a parameter of "1234.7z ". See that space at the end? That's the problem. If the file is "1234.7z" it won't exactly match "1234.7z " cause of the space. Adding wildcards before and after that incorrect string just makes it look for *1234.7z *. NOT *1234.7z*. therefore it doesn't match. this issue comes up because sometimes abuse report emails have spaces at the end of the filename being HTML emails and all.
   
   now, the real problem here never had ANYTHING to do with a regular bloody space. It was what the space was MADE OF that was the real issue. When I do conversions of abuse reports into my fancy new "rmq" tool (essentially a wrapper for find), I just copy and paste the email data out, format it a bit, and paste it into my terminal. The key here is that I am doing the email reading and formatting on a WINDOWS machine, specifically notepad (find/replace is so easy in it). So guess what gets injected: A non-breaking UTF-8 space character! That's not a normal space at ALL! That has a totally different hexadecimal code! And your terminal won't show it unless you pipe it into something like cat -A which shows all the control codes. Look at this echoing of the command I ran:
   
   echo rmq 6hu9hxxx.mp4 | cat -A
   rmq 6hu9hxxx.mp4M-BM- $
   
   "M-BM- " was the culprit (the dollar sign just indicates the end of a line - also if you guessed CRLF fuckery here such as needing dos2unix - you get an honorable mention). And the best part was that in my "rigorous" testing of the tool, I was just using a regular ol' space in the command line which is NOT the same space as the copy/pasted space which explains why it worked in that case but not in the real-world use of the tool I wrote. This failure in testing is such an incredible case study on how your testing of software MUST replicate the EXACT steps you expect a user or a software program to take - or this shit happens!
   
   So how do you fix this? Make sed deal with it and pass the results to your final command. My "rmq" tool now looks like this:
   
   input=$1
   trimmed=$(echo $1 | sed 's/\xc2\xa0/ /g')
   find . -type f -name $trimmed -delete -print -quit
   
   TL;DR FUCK MICROSOFT
   • Fish of Rage likes this.
   • Embed this notice
     7666 (7666@comp.lain.la)'s status on Saturday, 05-Apr-2025 02:40:18 JST 7666
     found that trailing whitespace in the parameter of a bash tool i use would make that tool fail to find explicit filenames. rather than rely on the user (me) to strip whitespace, my solution handles that for the user instead and is very simple.
     
     before: $1
     after: *$1*
     
     of course, said user had better not accidentally provide an input string that matches more than one file.