Live data from Hacker News

I'm “still afraid to use spaces in file names” years old

twitter.com

281–290 of 817 posts

Re: I'm “still afraid to use spaces in file names” years old

#281

Earlier quoted context omitted.

It doesn't even have to be complex, often basic automation tasks fail with spaces and special characters. Honestly, treating a file system like a natural language processor is a bad idea. Besides at this point with how digital we have all become who can't understand... thisismyconfig.txt vs this is my config.txt or this_is_my_config.txt ...i've forced myself to stop using spaces, character, and even cap. They are all…

> thisismyconfig.txt vs this is my config.txt or this_is_my_config.txt Just wondering, what is the readability of this for people who are dyslexic?

Or in my case, people for whom English is a second language, or have low education levels.

Saying, "who can't understand..." is arrogant, selfish, and an example of why normal people hate people in the SV echo chamber.

Re: I'm “still afraid to use spaces in file names” years old

#282
post #162

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.

A related too for CI: change the system time to be a time zone that is during your work hours in a different day already than UTC. Really helped getting failures earlier than 4pm PST.

Re: I'm “still afraid to use spaces in file names” years old

#283

Earlier quoted context omitted.

In my work, today's date would be 21K11, to save space over the longer date.

How do you distinguish 21K111 and 21K111?

Are you trying to catch GP on differentiating hours, were it to be appended to his time format (1st @ 11 vs 11th @ 1am)?

Notably he didn't promise any, but presumably one'd need a separator... Maybe, per his "K" usage of the month, one'd use the alphabet again. 11am would be "K" again... or lowercase just for giggles?

I don't think it reads very well, but I also think one'd get used to it pretty quickly.

Re: I'm “still afraid to use spaces in file names” years old

#285
post #90

Somehow the OneDrive clients still refuse to allow leading or trailing spaces in the filenames, along with a few other characters that are not allowed - seems to cause quite a bit of user friction at least with the non-tech guys that I work with who are confused about why OneDrive is one of the few file syncing clients that has these requirements....

Gdrive the same "issue". I think it's on purpose to avoid files that seems to have exactly the same name.

This can cause user confusion

Re: I'm “still afraid to use spaces in file names” years old

#287

I'm hardly afraid but I just think it's poor ergonomics. Same as the move from xset m 0 0 to xinput --set-prop 'pointer:Logitech USB Receiver' 'libinput Accel Profile Enabled' 0, 1 Everything seems to be going this way in Linux land. Longer names, harder to type names, camelcase names, spaces... I'm looking forward to an OS that treats command line ergonomics as a first class feature and where camelcase & spaces are…

Well, if you think that's bad, behold the recent trend in network interface names on Linux.

We started out with 'eth0', 'eth1', etc. Which adapter was which could change when adding and removing a network card. That was bad, so that prompted the evolution.

Now we have 'enp1s0', 'enp0s31f6', 'enp13s0' and many similar variations. These are supposedly more stable across device changes. As it turns out, it wasn't.

But wait, there is more! Now we have the "predictable names" scheme that produces interface names that are even longer, and not even slightly easier to remember.

Read about the whole sorry saga here:

https://wiki.debian.org/NetworkInterfaceName

I do get that it is not an easy problem to solve, especially in the face of removable network interfaces (like USB Ethernet / WLAN). But surely this is not the best we can do.

Re: I'm “still afraid to use spaces in file names” years old

#288

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…

Better solution: only allow ASCII, maybe dashes, and up to twelve characters. Problem solved. Enforce this in LDAP. Strict convention is better than flexibility and predicting obscure edge cases that can fail.

only allow ASCII, maybe dashes, and up to twelve characters. Problem solved

...and only hire people from the exact same background as you, who will never have unusual characters or accents in their name. And also make sure not to have any users who aren't exactly like you, and conform to this very narrow requirement. Surely, excluding 90% of the world won't hurt revenue in any way.

Re: I'm “still afraid to use spaces in file names” years old

#289

Earlier quoted context omitted.

Sure. One could also make "move-down-one-line" be the incantation to move the cursor down a line in vi, but I prefer j. Ergonomics isn't all about making everything self-descriptive for someone seeing the thing for the first time. It's about making things comfortable to actually use. If it's so long and complicated that you can't even remember how to do it, it's not very comfortable to use. Even if I could remember,…

> Ergonomics isn't all about making everything self-descriptive for someone seeing the thing for the first time. We're talking about `xset`. It doesn't make sense to optimize that for usage of more than once a year.

The less frequently I need something, the more frustrating it is if it's not short and memorable (or easy to look up in the synopsis or built-in help). Forgetting and googling a needlessly complicated command over and over again every year isn't fun.

xset achieves that perfectly. If I somehow didn't remember how to set mouse acceleration with it, a quick glance at the synopsis immediately tells me. Or I can just run the command and it'll tell me:

    To set mouse acceleration and threshold:
         m [acc_mult[/acc_div] [thr]]    m default
Zero frustration, and the command is so short and simple that I end up remembering it without trying.

This is something I've observed more than once: I easily memorize useful sets of one-letter flags even if I can't remember or know what they all stand for. This just doesn't happen nearly as much with long options. Commands like ls -ctrl or ss -nap quickly become part of my repertoire even if I don't use them very often, but I really couldn't remember ss --numeric --all --processes (if I had written that from memory, it could've ended up as --num --all --pid or --numeric --any --process), and I don't even know what the corresponding long options for ls are. In the rare case when I have to deal with an option that has no short equivalent, I feel like I have to look it up every time if it's been longer than a few weeks.

You talk of optimization but I think this is just a very basic (and reasonably successful) attempt at sane design. It's not like someone had to go far out of their way to make this in a manner that isn't batshit insane.

Post reply on HN