this post was submitted on 27 Feb 2024
404 points (97.9% liked)

Open Source

31665 readers
409 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS
 

Yet another "brilliant" scheme from a cryptobro. Naturally this caused a gold-rush for scammers who outsourced random people via the gig economy to open PRs for this yml file (example)

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 9 months ago

Its easy for me to say "just start writing JSON in the yaml. It doesn't get more simple than JSON", but actually I do think there's a small point with the unquoted strings.

Back before I knew programming, I was trying to change grammar settings sublime 2, which uses yaml. I had no idea what yaml was. The default setting values used unquoted strings fot regex. I knew PCRE regex and escapes, but suddenly they didnt work, and when I tried to match a single quote inside of regex that also didn't work. I didn't know I was editing yaml file (it had a .tmLanguage extension). Even worse, if I remeber correctly, unparsable settings just silently fail. Not only did I have no errors to google, I didn't have any reason to believe the escapes were the cause of the problem (they worked in the command line). Sometimes I edited the regex and it was fine, and other times it just seemed to break. I didn't learn about quoting in YAML until years later.

For me that was an unfortuate combination, which was exacerbated by yaml unquoted weirdness. But when you're talking about "did you read the spec" that's a whole other story. .nan for nan, tabs vs spaces, unquted string weirdness, etc should just be one error message+google away. I think they're a small hiccups with what is overall a great format.