Dealing with spaces while scripting or in terminal is such a pain in the ass. The true dark path of horror is using spaces indeed.
Piracy: ꜱᴀɪʟ ᴛʜᴇ ʜɪɢʜ ꜱᴇᴀꜱ
⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.
Rules • Full Version
1. Posts must be related to the discussion of digital piracy
2. Don't request invites, trade, sell, or self-promote
3. Don't request or link to specific pirated titles, including DMs
4. Don't submit low-quality posts, be entitled, or harass others
Loot, Pillage, & Plunder
📜 c/Piracy Wiki (Community Edition):
💰 Please help cover server costs.
Ko-fi | Liberapay |
[This comment has been deleted by an automated system]
I work on a Web app and we recently decided that we're just not gonna support double quotes in free text fields because oh holy balls what a thing it is to try to deal with those in a way that doesn't open you up to multiple encoding vulnerabilities.
That's... Surprising. If you're doing things right, double quotes should be no trouble at all:
- HTTP requests have simple, automatic encoding
- SQL queries with prepared statements don't need any special handling for double quotes
- Rendering the data should happen with proper escaping etc.
They are usually only trouble if you're doing SQL queries wrong (concatenation etc.) or if you're not escaping your output.
The issue is the filter that we're using to avoid multiple encoding attacks de-escapes everything via multiple rounds, then tries to pass it to the next layer of filtering with the de-escaped request body as a json string. Your absolutely right that this is a silly way of doing it, but sometimes we have to live with decisions that were made before we were onboarded to a project. In this particular case, I pushed to improve the filters but all our PO heard was "spend development time weakening security" and at the end of the day they decide what to do and we do it.
Ah, that's understandable. Sorry you have to go through that!
It's a way bigger pain in the ass than people think it is. I remember having to parse output from a tool for work that had tons of output in tabular format, mixed with normal sentence like strings. JSON, YAML, or XML outputs weren't available so I had to do a nasty mess of grep, awk, cut, and head/tail, to get what I wanted. My first attempt was literally counting the characters so I could cut out exactly what I needed, but as we all know, hardcoding values is a recipe for headaches later on.
Here's a horror story from literally yesterday. We have been fighting a system for a client for weeks and it has been a nightmare. Our clients just told us that they outsourced some of their work to an Indian outfit but that outfit is unfamiliar with Linux and doesn't know how to edit text files so they have been downloading the files to their Windows machines, editing them in Windows, then uploading the contaminated text files back into Linux. None of them, not our client nor the outfit they hired, understood why this was a problem. We have no idea what files are affected and we won't know until they fail because they obviously did not keep track of what they touched.
EDIT: I'm being intentionally vague.
Haha this is up there with having to explain why opening a csv in Excel and then saving means that I don't want the file.
I will never forgive excel for automatically converting all of my dates to some weird ass format, or stripping single quotes randomly, or something other BS that they do for no reason
The only reasonable response to this behavior is disproportionate violence
If this is about line endings, surely a simple shell or python script could correct them?
You can just grep for carriage returns followed by newlines, grep -Pirn '\r\n$' /path/to/whatever
. It'll identify all your problematic files.
“\ “ and [tab] and * are your friends. I’ve been using spaces in Unix filesystems since the early 90s with no issues. Also, using terminal fonts that•put•a•faint•dot•in•each•space•character helps.
Yeah, either put quotes around it '/like this/you can incorporate/spaces/into your paths' or /just\ escape/your\ spaces/like\ this
This is fine for the most basic of use cases but once you start looping through file names or what have you, you have to start writing robust correct bash and nobody does that
It gets real crazy when you're sending remote commands so you have to escape the escapes so that the remote keeps them and properly escapes the space
ssh -t remote "mv /home/me/folder\\\ with \\\ spaces /home/me/downloads/
Yeah I was gonna say this is something anyone in tech knows, spaces are a plague
This is scene, there are standards goddammit!
Yes, there really are.
I prefer dots over spaces.
Spaces can mess with stuff, double space...
Either are fine, I just wish there was a more consistent standard like naming ROMs. I want to be able to script renaming everything for Kodi
Look up SMDB (smoke monster's database). You can download a tool (I forget what it's actually called, I think one is called ROM manager) which reads the SMDB files and compares the hashes to your ROMs and will categorize and rename them for you. It looks for duplicates, unofficial releases/hacks/patches, categorizes them by country (US, EU and Japan largely), and more. It's a pretty nifty tool.
I spent like two hours going through PS1 ROMs and was like "there's got to be a better way!" (insert cheesy black and white infomerical cutaway), started looking up stuff and there it was. Not all game systems are supported (mostly NES, SNES, Genesis/MegaDrive, and a few others) but you can build SMDB "packs" yourself.
I forget if it works on Windows, but I know it works on Linux and it's either a script or a compiled binary, I forget which, but you can definitely script it, I've done so myself since the command string tends to be a bit long.
I think your workflow is not optimal. Are you using software like Radarr and Sonarr? They do the renaming for you and come with Kodi integration. Or is this not feasible?
why not use underscores?
I've always liked underscores better because it differentiates from the file extension. It just makes sense. Except it is a wider character, so it'd be longer.
well if you're using a mono font (terminal) then there are no such thing as wider characters anyway, so for me that's not a drawback either
Using spaces is so inconsiderate.
It's quite strange, I've been downloading torrents for more years than I can count, and I upload them from time to time, and I've always had the worry myself of how to name torrents: with dots? underscores? dashes? (although with spaces is definitely not an option).
I've even asked the questions on several forums and upload sites, read tutorials on these same sites etc and every time I've asked the answer has been: THERE IS NO STANDARD, even on the tutorials, I've never seen anything mentioned such a thing.
All this to say that I'm making a meme, and after so many years, this is the first time I've heard of a Warez scene, and several times in the same comments!, curious, isn't it? I wish I'd heard about it before.
You should know that in most filesystems that are not NTFS, spaces in file names are not well supported.
As soon as the file finishes downloading it becomes only the name of the movie.filetype
I can't stand the titles on torrents.
“Titles”? It’s not a title, it’s a file name that contains a lot of details about the rip. In the post’s example it tells you that it’s the movie Split, ripped from blu ray, in 1080p, with audio tracks in Italian and English, and encoded in x265. You probably would hate a lot more not being able to tell the difference between split.mp4 recorded on my cellphone in the movie theater and split.mp4 in ultra hd 4k ripped straight from Netflix.
Why are spaces bad? Does it mess with sonarr/radar or something?
It's legacy, white spaces weren't allowed as characters on most FTP software, which is how the warez scene shares it's releases. It used to be underscores, but dots are closer to a white space regarding separation (space wise), so most release groups use dots nowadays.
Generally, a white space as a character in filenames and directories is "frowned upon" in many operating systems, Windows included (somewhat). It makes writing scripts and software more comlicated because it's used as as a separator for giving command line/terminal options to commands and binaries (programs).
it goes way back before ftp.. i believe its because the original operating systems filesystems/namespacing could not handle the space character at all. so all files lacked spaces in their names. but only for like the first 30 years
Yes, you're correct, it goes much further back than FTP, all the way down to UNIX I believe. The problem was commands and parameters (options) which use a white space to seperate between them. So, filenames and directories were't allowed to have white spaces in them.
Spaces are a headache whenever you're not using a graphical interface.
Should be a hyphen instead of period before NAHOM.