191–200 of 817 posts
I am also that age, and kebab-case is the best case for filenames. 2021-01-01-some-important-document.pdf gives me the warm fuzzies. On the off chance that some more differentiation is needed, throw in an underscore and a whole new world opens up
> kebab-case I hadn't heard that before and I love it.
Earlier quoted context omitted.
"Documents and Settings" still exists on Windows 10, as a soft link to "Users".
You know, this makes me wonder.. tangentially speaking- I wonder how hard it would be to rearrange the folder structure in linux so that I have something like this: /Users/{root, user0, user1, ... }... /System/{Logs, Apps/{opt, container, ...}, Temp, Conf ...}... /Devices/{Mount, sda, sdb, null ...}... /Boot/...
I work on a complex desktop application, and it's been astounding the number of bugs that have appeared over the years triggered by spaces and other unusual characters in file names. If you do anything with subprocesses or path processing, it's absurdly easy to hit in a thousand different ways, over and over again. Pro tip: rename your development directory (or even better: the workspace path in CI) to put a space an…
> Pro tip: rename your development directory (or even better: the workspace path in CI) to put a space and/or special characters in it. A former co-worker changed his name in our auth system to include an apostrophe, so that whenever we handled names wrong he'd find it.
I am also that age, and kebab-case is the best case for filenames. 2021-01-01-some-important-document.pdf gives me the warm fuzzies. On the off chance that some more differentiation is needed, throw in an underscore and a whole new world opens up
Earlier quoted context omitted.
Seems like MS had the same idea according to an answer in the link: > Microsoft intentionally made programs install to C:\Program Files on Windows 95+ to force programmers to deal with spaces in filenames.
Laughs in C:\PROGRA~1\ (try it, still works in Windows 10)
I have an uneasy feeling whenever I see a path parameter declared as string. Path is not a string - it's a sequence of path components and should be treated as such by our APIs. A path should be parsed once - on user input - and then used in its "sequence form" throughout the software stack. And "path component" is not an arbitrary string either - e.g. appending a path component to the path should first require conve…
"Path is not a string - it's a sequence of path components and should be treated as such by our APIs." For maximum correctness, you want to turn it into a file handle as soon as possible, and do all operations through the variations of the file functions that end in "at", like: https://linux.die.net/man/2/openat The downside of this approach is that you still technically have to carry the path around with you if you…
But no sooner.
For example, I've run into problems where I'm configuring program A server to talk to file location B... but I don't have access to file location B. But the client-side library for talking to the server tries to convert location B into a file handle and then freaks out because I can't access it. When I don't want to access it. I want that program to serve it.
If it was using simple "path" objects that didn't confirm that I have access to the path, everything would be hunky dory. But because it tried to convert it into a file handle unnecessarily, I get blocked.