But if someone creates a file called HEAD, should it overwrite a file called head?
That shouldn’t matter to the “nontechnical” end-user at all. To the nontechnical user, even the abstraction of “creating a file” has largely gone away. You create a document, and changes you make to it are automatically persisted to storage, either local or cloud.
Only the technical command-line user cares about whether /usr/bin/HEAD and /usr/bin/head are the same path. And only in a specific circumstance — such as the early days of Mac OS X, where the Macintosh and Unix cultures collided — could the bug that I described emerge.
I found this post confusing because on the face of it, it sounds like you agree with me.
I mean, yeah, HEAD and head should overwrite each other.
As you say, only technical command-line users care about the case sensitivity. So no, it shouldn’t matter to the nontechnical user. And because the nontechnical user doesn’t care about the distinction if something is called “head” in any permutation it shares a name with anything else called “head”. And the rules are items within a directory have unique filenames. So “head” and “HEAD” aren’t unique.
The issue isn’t that the names are case insensitive, the issue is that two applications are using the same name in the same path.
If we’re not careful that’ll lead to a question about whether consolidating things in the Unix-style directory structure is a bad idea. I normally tend to be neutral on that choice, but you make a case for how the DOS/Windows structure that keeps all binaries, libraries and dependencies under the same directory at the cost of redundancy doesn’t have this problem to begin with.
But either way, if two pieces of software happen to choose the same name they will step over each other. The problem there is neither with case sensitivity or case insensitivity. The problem there is going back and forth between the two in a directory structure that doesn’t fence optional packages under per-application directories. As you say, this is only possible in a very particular scenario (and not what the post in question is about anyway).
But if someone creates a file called
HEAD, should it overwrite a file calledhead?That shouldn’t matter to the “nontechnical” end-user at all. To the nontechnical user, even the abstraction of “creating a file” has largely gone away. You create a document, and changes you make to it are automatically persisted to storage, either local or cloud.
Only the technical command-line user cares about whether
/usr/bin/HEADand/usr/bin/headare the same path. And only in a specific circumstance — such as the early days of Mac OS X, where the Macintosh and Unix cultures collided — could the bug that I described emerge.I found this post confusing because on the face of it, it sounds like you agree with me.
I mean, yeah, HEAD and head should overwrite each other.
As you say, only technical command-line users care about the case sensitivity. So no, it shouldn’t matter to the nontechnical user. And because the nontechnical user doesn’t care about the distinction if something is called “head” in any permutation it shares a name with anything else called “head”. And the rules are items within a directory have unique filenames. So “head” and “HEAD” aren’t unique.
The issue isn’t that the names are case insensitive, the issue is that two applications are using the same name in the same path.
If we’re not careful that’ll lead to a question about whether consolidating things in the Unix-style directory structure is a bad idea. I normally tend to be neutral on that choice, but you make a case for how the DOS/Windows structure that keeps all binaries, libraries and dependencies under the same directory at the cost of redundancy doesn’t have this problem to begin with.
But either way, if two pieces of software happen to choose the same name they will step over each other. The problem there is neither with case sensitivity or case insensitivity. The problem there is going back and forth between the two in a directory structure that doesn’t fence optional packages under per-application directories. As you say, this is only possible in a very particular scenario (and not what the post in question is about anyway).