Hacker News Reader

Comment by codedokode | Hacker News Reader

Starting directory names with capital letter is not a good idea. While that might look nice, it requires more keypresses when typing it in the terminal. So /apps or /soft would be better than /Programs.

It is convenient in case-insensitive filesystems like those used in Windows or Mac, but not in Linux. By the way it would be better if Linux also switched to case-insensitive filesystem, or even a filesystem where similar looking characters from different alphabets are considered the same. So that A is always A no matter what alphabet is used.

Also I don't like the way they hide classic directories like /bin. Instead, they should just not create these directories; well-written programs should not require their presence.

View on HN

The response by one of the devs to the first problem is "In fact, the concerns on typing-friendliness always comes up in discussions about the GoboLinux tree. To that, I can only respond that, in a properly configured shell like the one that comes by default with GoboLinux, typing /Programs takes the exact same number of keystrokes as typing /usr: slash, lowercase p, Tab." [0]

The response to your second problem is that not all programs are well written, and they cannot afford to patch every poorly-written program.

[0] https://gobolinux.org/doc/articles/clueless.html

I don’t want to have to reconfigure a shell when it could just be lowercase.

I hear you, but I also think tab completion is one of the basic amenities we should expect shell users to avail themselves of in 2021. And distro-makers can even pre-configure them for their users. I can understand why a distro maker might not be interested in accommodating users who don't want to use decent tab completion with smart casing.

Yes I agree, just playing devils advocate that you shouldn’t have to change off defaults for ergonomics when there isn’t a real _benefit_ to pascal case.

I agree that PascalCase makes more sense on systems like Windows, where everything is case-insensitive, or in shells like PowerShell, where virtually all commands are shell functions rather than separate binaries, and the shell itself is case-insensitive. Then, I suppose you get some legibility benefit, without any extra hassle.

I'm personally still on the fence about the more verbose style. I think I like it for directory names but not really for executable names.

in other words, they haven't thought to make the damn name and case-sensitivity preferences configurable. how odd is that.

The reason you don't see "hypertexttransferprotocoloverssl://" in that address bar right now is not the lack of tab completion.

From the faq it sounds like the purpose is to differentiate the gobolinux top level folders from the hidden compatibility folders, which makes sense to me.

Case insensitivity is a mess as soon as you start looking outside of ASCII.

But I don't think that it is an unsolvable task. If you simply use Unicode-aware version of "to lowercase" function, it will be better than what we have today. But of course there is a place for improvement (dealing with accented letters in European languages, dealing with combining characters, different alphabets like Hiragana/Katakana etc).

Hum... I think simpler is better, and having each letter be what they are only seems much simpler than having to guess if the file system is going to decide my new file name is equivalent to another existing file name and overide it rather than creating a new one (for example).

It is "simple" for a programmer who doesn't want to learn Unicode and prefers working with bytes instead of letters, but inconvenient for a user. More keypresses, easier to make a mistake when typing.

I cannot imagine a situation where you need two files whose names differ only in case.

Since it's relevant and funny, I'll quote the famous rant of Linus Torvalds on the topic (it was because of issues it caused with Git, but I assume it still means it's unlikely Linux will ever follow this path ^^)

"The true horrors of HFS+ are not in how it’s not a great filesystem, but in how it’s actively designed to be a bad filesystem by people who thought they had good ideas.

    The case insensitivity is just a horribly bad idea, and Apple could have pushed fixing it. They didn’t. Instead, they doubled down on a bad idea, and actively extended it – very very badly – to unicode. And it’s not even UTF-8, it’s UCS2 I think.

    Ok, so NTFS did some of the same. But apple really took it to the next level with HFS+.

    There’s some excuse for case insensitivity in a legacy model (“We didn’t know better”). But people who think unicode equivalency comparisons are a good idea in a filesystem shouldn’t be allowed to play in that space. Give them some paste, and let them sit in a corner eating it. They’ll be happy, and they won’t be messing up your system.

    And then picking NFD normalization – and making it visible, and actively converting correct unicode into that absolutely horrible format, that’s just inexcusable. Even the people who think normalization is a good thing admit that NFD is a bad format, and certainly not for data exchange. It’s not even “paste-eater” quality thinking. It’s actually actively corrupting user data. By design. Christ.

    And Apple let these monkeys work on their filesystem? Seriously?"

I can think of one. When we write (say "ES6") modules it makes sense that the name of the module-file without extension should be the same as the value exported by that module.

Inside the module you'd prefer to follow conventions like name classes title-case and name functions camel-case.

Thus you might have one module exporting a class named "Camel", and another module exporting a function named "camel". You could then have two files, Camel.js, and camel.js in the same directory, containing two separate programs.

> If you simply use Unicode-aware version of "to lowercase" function […]

There's no such thing. What's the lowercase of ‘I’ — ‘i’ or ‘ı’?

That's the "place for improvement" you shoved into the "[...]".

Pick something.

Pick something? Whatever you pick is wrong for some users.

And busted unicode support is more wrong.

Also you don't need to have an opinion on how to lowercase, you can just say that İIiı are equivalent and it shouldn't make people that upset.

Case-insensitive ASCII filenames are best filenames.

Also, please, no whitespace in filenames. Allowing linebreaks is just insane.

I wouldn't mind but there are a bunch of people in this world who have no idea what those ASCII symbols even mean, and who might prefer using symbols they understand ^^

Those people do not use filesystems.

Also, my native language does not use the Latin alphabet. Attempts by American companies to be more inclusive and internationalized are often misguided. MS is especially nasty with its translated formula functions in Excel, but having differently named filesystem paths in different alphabets depending on the phase of the Moon or something is also very inconvenient.

Oh yeah Excel (or libreoffice) is really awful to use in another language, I often have to force it to English because of the formula mess. But I guess that's a developer-who-can-speak English point of view.

Nah, the names of Excel functions are nonsensical in any language, and you still need to know the English ones.

Though I do have to admit that I do not know what, e.g., ASCII code 8 would mean in a filename. Or 27. I’d very much prefer using symbols I understand.

Filenames with terminal control escape sequences are lots of fun.

Limiting possibilities to just lowercase Latin, numbers, periods and dashes (in non-initial positions) decreases chances people see symbols they do not understand by a lot.

I think one criterion could be that you should be able to identify a name by its pronunciation. The same utterance should always refer to the same thing on the computer. When you speak you don't speak line-breaks. By the same logic commas should not be allowed in names. And when you speak we don't typically hear whitespaces either.

By the same logic the whitespace sensitivity of Python is a bad idea. :-)

My criterion is that paths should not be painful to type, parse, or copy-paste. So no keyboard layout switching, and escaping should not be necessary. Lower-case Latin letters, digits, periods, and dashes (of the unique variety that's available on keyboards, and not in the initial position) are simple and enough.

I think bash autocomplete can be configured to be case insensitive

Case sensitivity is a good idea for sorting/identifying between files/directories.

Reply on news.ycombinator.com