Live data from Hacker News

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

twitter.com

291–300 of 817 posts

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

#291

Earlier quoted context omitted.

the most used options for properly written tools have both short single char option like -c and long-form version --config if you need verbose self-describing option. If you are using cli tools of github written by a random person, then no wonder you will see non-standard approaches to UX.

PowerShell takes an interesting approach in that it accepts any truncated variant of a long-form flag as a short form, provided it isn't ambiguous (i.e. if the interpreter can't decide which long-form flag to expand a short-form flag to.) For example, if a command features a "-ConfigFile" flag, valid short-form variants include "-C", "-Co", "-Con", "-Conf", and so on. But if the command featured an additional flag "-…

getopt_long (and thus most GNU programs) work this way. I think it's probably a misfeature though since it means that adding a new option can introduce ambiguity. Having both short (ex. -x) and long (ex. --exclude) options is a less problematic solution.

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

#292
Every week, I encounter a user - just like I did in the 80's - who cannot explain the difference between a file and a folder.

"What do I use a folder for?", they ask, in the same breath that they request "some way to organize things logically".

The no-filesystem movement has worked hard to eradicate this scourge from user experiences, but I fear that this is the devils work. Computer users should know what a file is, and what its for - and they should know what a folder is for, and why they would want to create one to put their files into it ..

But yet: they don't.

It hasn't improved since the 80's. Taking away the users responsibility to understand these things, only makes computing worse. The fact that "special chars in paths" breaks things, also holds this factor into place, imho.

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

#293

Still way too many libraries and programs can't handle spaces in filenames. And shells and other programs still have problems with perfectly legal characters in filenames too, like '!' or ':'.

> And shells and other programs still have problems with perfectly legal characters in filenames too, like '!' or ':'. Without asking you to always quote and escape every file name - what alternative is there? If they tried this you'd probably find you didn't like it.

Not exactly - the problem is mostly when doing variable expansion. The fact that bash treats "$x" and $x as different is a bit of a design flaw. Of course there's still an issue with evaluating dynamically generated code, but that problem is partly solved by working with arrays.

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

#294
post #190

Earlier quoted context omitted.

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/...

GoboLinux does exactly that: https://en.m.wikipedia.org/wiki/GoboLinux

Dammit, I wanted to be the one to mention gobo linux [HN deleted my laughing emoji ffs]

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

#295

Earlier quoted context omitted.

That order is not guaranteed consistent across installations, however.

I wonder if code to this effect has ever been written before for (int i = 1; i

And that, children, is when marginalia_nu unlocked the seventh circle of the inferno. Tomorrow we'll read the story of how our new demon overlords forced us all back to Windows 3.1.

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

#296
post #157

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)

Apart from what others mentioned, that can only work if the file system automatically creates 8.3 names. NTFS does not necessarily do that (https://docs.microsoft.com/en-us/windows-server/administrati...)

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

#297

Earlier quoted context omitted.

I wish they did "User Files" instead of "Users" too, because so much software breaks on the home area having a space in it. Not least, it makes writing scripts for various shells and getting the quoting rules right an absolute pain as well...

Huh, spaces. There's way too much software, especially on Windows, that breaks when there are Cyrillic characters in a path. I'll let you guess how I found out.

A friend had the username "Rubén" and jfc it broke everything other than windows itself xD

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

#298
post #190
post #173

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/...

macos does something like that.

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

#299
post #279
post #159

Earlier quoted context omitted.

but the extra Shifts, no thank you

you gotta involve your pinky or it'll atrophy

Cut most mine off in an unsupervised Halloween pumpkin carving accident when I was a kid. I think the lack of length actually allows me to type faster.

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

#300

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…

> I have an uneasy feeling whenever I see a path parameter declared as string. Path is not a string I guess that depends on what you mean by "string". `open` and `fopen` need a char* path to open a file. Whatever fancy Path abstraction you use eventually becomes a char* string, because that's what the kernel needs.

yeah. it's a string.
Post reply on HN