[jzdziarski]

... that all unix commands are treated as case IN-sensitive in OSX.

[lookmark]

Sickening?

Reformat your HD in case-sensitive HFS+ if you can't live w/o it.

[Chuckit]

Case sensitivity is a property of the file system. If you're using a case-sensitive file system (UFS, for example), case will make a difference.

Also, I'm not really sickened by the fact that both TOP and top do the same thing. It seems kind of logical, really.

[Detrius]

Originally posted by jzdziarski:
... that all unix commands are treated as case IN-sensitive in OSX.

Case sensitivity in a file system is a bad idea anyway. How are you supposed to distinguish between README and ReadMe? Which one is which?

[Big Mac]

I am slightly sickened by poor thread titles.

[yukon]

Lock? Unbacked opinion posted for trolling.

[Twilly Spree]

Originally posted by jzdziarski:
... that all unix commands are treated as case IN-sensitive in OSX.

You mean there is no difference between say, ls and LS?

[Millennium]

Sickening? Au contraire; frankly it's a usability thing which has always bugged me. Why should case matter? I've never heard a good reason for it.

[Randman]

Originally posted by Big Mac:
I am slightly sickened by poor thread titles.

Ditto.

[Twilly Spree]

Originally posted by Millennium:
Sickening? Au contraire; frankly it's a usability thing which has always bugged me. Why should case matter? I've never heard a good reason for it.

Same reason that written text is case sensitive in general.

I heard Panther offers HFS+ with case-sensitivity.. so no big deal. Turn it on if you like, turn it off if you don't like..

http://www.macosxhints.com/article.p...00502011939237

[d0ubled0wn]

Yeah I puked when I found that out too. Bad GUI design also make me naseous and physically ill.

[tooki]

Originally posted by Twilly Spree:
Same reason that written text is case sensitive in general.

No, not really. Case is an arbitrary notion, put there almost exclusively for legibility reasons. Many writing systems have no equivalent to case, by the way.

tooki

[Twilly Spree]

Originally posted by tooki:
No, not really. Case is an arbitrary notion, put there almost exclusively for legibility reasons. Many writing systems have no equivalent to case, by the way.

tooki

Naturally I am talking about the English language, since the computer systems in question are made by us English speaking people.

In English there is a difference between Smith and smith. They are not the same thing.

[omar96]

if it really bugs you that badly, just type them the way they were "meant" to be...like ls, rm, cp, etc...it's not that hard...

[Tsilou B.]

Originally posted by Twilly Spree:
Naturally I am talking about the English language, since the computer systems in question are made by us English speaking people.

In English there is a difference between Smith and smith. They are not the same thing.

Yes, and that's why HFS has always been a "case-preserving" file system. When you name a file "smith", it will never show up as "Smith" or "SMITH". However, that does not mean that it has to be allowed to have several files in the same directory that only differ in case.

If I write a story about Mr. smith, you would certainly assume that I just made a simple mistake and wanted to write about Mr. Smith. You would never think: "Huh? What strange blacksmith is he talking about?". When I write about Steve jobs, you would never assume that a "Steve-job" is a special kind of job, named after its inventor, Mr. Steve.
It's just the same with the Mac. When you save a file called "Smith" and then tell the Mac to copy file "smith", the Mac thinks that you meant "Smith" and only forgot to press the shift key. I think that's a good idea and user-friendly. If others disagree, no problem, but it's really not hard to imagine why the creators of the Mac chose this (more difficult) approach.

[Zarafa]

Originally posted by Detrius:
Case sensitivity in a file system is a bad idea anyway. How are you supposed to distinguish between README and ReadMe? Which one is which?

By the contents. Or size. Or position in the filesystem. Or author. Or creation date. Or last-modified date. Or any one of many other attributes. This is much the same way that, for instance, you can distinguish between multiple emails of the same title, or multiple songs with the same or similar titles.

I grant that these methods of discovery are not [yet] exposed through the Finder, shell commands, or other methods adequately. Certainly email messages and music files are much easier to distinguish in their respective applications than are "regular" files in the filesystem.

Using a file name is kind of a silly concept in the first place. There aren't a lot of other situations in the world where a name (by itself), or case, is the only piece of data used to identify an object [e.g. I share a name with someone in my company -- yet there is almost nothing, other than emplyer, that is similar about us otherwise, and people have confused us, even in email, no more than I've been confused with others who might share some similar roles, or have similar phyical characteristics as me].

Forcing an object to even have a name doesn't make too much sense, when you really think about it. I have notes throughout my [physical] filing system, on my desk, in my wallet, etc. that are all untitled. Yet the content, intent, author and other characteristics are readily apparent.

In a filesystem that acts like a database, names shouldn't have any special significance. There's no reason any number of files shouldn't be able to have the same name (or no name) within a given directory, especially as the concept of fixed directories slowly loses relevance. Within "Smart Folders" (iTunes, Tiger, etc.) it's certainly possible to have files that share names [including case].

It is certainly true that "behind the scenes", computers will have to track each file by some sort of unique identifier. That's OK, they're good at that sort of thing; do you worry about the session ID of each of your TCP transactions, for instance? But within the normal user-exposed view of files, names shouldn't impose the constraints that they do now.

I will leave some of the usability issues -- how to best expose metadata to visual or other inspection in a readily-apparent manner -- to the experts , though I submit that iTunes, any good email application, and similar apps for other types of media have already started down the path of solving these sorts of things.

[chris v]

Somebody somewhere (or a group of sombodies) decided that case sensitivity was a bad idea in the GUI as well, and I agree. You could have an almost endless number of files with essentially the same name, otherwise. Would you really want a folder full of:

smith.rtf
smith.RTF
Smith.rtf
SMITH.rtf
Smith.RTF

etc.

I think not. It would lead to clutter and confusion.

[TETENAL]

Originally posted by Twilly Spree:
Same reason that written text is case sensitive in general.

These are beautiful flowers. Flowers are nice in general, but those are gorgeous.

Written text is case sensitive? So "flowers" and "Flowers" are different things?

[Twilly Spree]

Originally posted by TETENAL:
These are beautiful flowers. Flowers are nice in general, but those are gorgeous.

Written text is case sensitive? So "flowers" and "Flowers" are different things?

You only think you are making a point. Or you're being obtuse. I'm not sure which..

[TETENAL]

Capitalization is little more than decoration.

All texts can be read and still retain their meaning. There is no capitalization in speech.
Up until the middle ages there was no capitalization in written texts. Again no problem.

[jzdziarski]

Apart from your philosophical considerations, which I emphatically disagree with, the bigger problem is that it's incompatible with any *nix operating system that *does* recognize case, which could lead to potential data loss if you happen to have two files with the same filename (but different case). I've seen a few problems with some files I've been bringing over.

If this was a simple switch that might be one thing, but to have to rewire the filesystem to fix this is a bit extreme.

[tooki]

Originally posted by Twilly Spree:
You only think you are making a point. Or you're being obtuse. I'm not sure which..

No, he proved my point succinctly. Capitalization in non-UNIX use is largely, yes, "decoration".



UNIX's decision to be fully case-sensitive is more likely a result of more simplistic coding than of an informed user interface evaluation: it takes a LOT more work to make a case-insensitive filesystem!

Again: most UNIX utilities actually work fine on the case-insensitive filesystem, and if you really need to, you can make it case-sensitive! So what is all the fuss about?!?

tooki

[Chuckit]

Originally posted by jzdziarski:
Apart from your philosophical considerations, which I emphatically disagree with, the bigger problem is that it's incompatible with any *nix operating system that *does* recognize case, which could lead to potential data loss if you happen to have two files with the same filename (but different case).

1. Again, case sensitivity is a file system feature. It isn't a feature that exists on other Unices but not in OS X.

2. Mac OS X is not the lowest common denominator. Case sensitivity is a confusing misfeature with no real use, and I'm glad that Apple made the default file system one that doesn't include it. You really shouldn't have made file names that lead to this problem in the first place, but if having confusingly similar files is that important to you, you should have chosen a case-sensitive FS to begin with.

Originally posted by jzdziarski:
If this was a simple switch that might be one thing, but to have to rewire the filesystem to fix this is a bit extreme.

To have to rewire the file system to change the file system seems pretty logical to me.

[jzdziarski]

I suppose next you'll be telling me that 8 characters + a 3 character file extension is all I need?

[Chuckit]

Originally posted by jzdziarski:
I suppose next you'll be telling me that 8 characters + a 3 character file extension is all I need?

How is that in any way comparable? I say case sensitivity is a misfeature that serves no purpose except to confuse people, and you somehow read in that I prefer 8.3 file names? Both 8.3 file names and case sensitivity are bad ideas caused by lazy programming that lead to a less readable file system.

[Big Mac]

Originally posted by jzdziarski:
I suppose next you'll be telling me that 8 characters + a 3 character file extension is all I need?

That's a pretty crappy strawman you've got there. The Mac never had and will never have a DOS style filename limitation. I could also contend that case sensitivity is almost as backward as the DOS name convention.

[Gee4orce]

LS
tcsh: LS: Command not found.


What are you talking about - LS doesn't work on my system, ls does.

The Mac OS has always been case preserving but not case sensitive - it you want to call a file ReadMe then that's up to you, but you shouldn't use it to distinguish that file from readme or REAMDE or rEADmE

[msuper69]

Mickey:~ Mike$ LS
Desktop Icon? Pictures
Desktop DB Library Public
Desktop DF Movies Sites
Documents Music Temporary Items
Downloads Network Trash Folder TheVolumeSettingsFolder

LS works just dandy for me. Must be the shell. Bash ok, tcsh not ok?

[Agent69]

jzdziarski,

Like you, I don't care for the case insensitive nature of the default Mac OS X filesystem. But I think you are going to find that unlike you and I, most people here on MacNN actually prefer it that way.

Personally, I have been hoping that case sensitive HFS+ will be an install option for Tiger client, but I am not holding my breath for it.

[chris v]

Originally posted by Gee4orce:
LS
tcsh: LS: Command not found.


What are you talking about - LS doesn't work on my system, ls does.

Try bash instead of tcsh.

[P]

Originally posted by msuper69:
Mickey:~ Mike$ LS
Desktop Icon? Pictures
Desktop DB Library Public
Desktop DF Movies Sites
Documents Music Temporary Items
Downloads Network Trash Folder TheVolumeSettingsFolder

LS works just dandy for me. Must be the shell. Bash ok, tcsh not ok?

% LS
tcsh: LS: Command not found.
% exec bash
$ LS
<list of files>

Yep, that seems to be it. Some sniffing around confirms this: tcsh builds an internal hash of executable programs at startup, and then compares the commandline to this. Tcsh is a UNIX program and assumes case sensitivity - the comparison with the hash is case sensitive, no matter what HFS+ does.

Bash simply tucks on the command on the command line onto each directory in the path and tests for that. Since that test is dependant on the filesystem, HFS+ makes it case insensitive.

There is actually a bug in bash' handling of this. If the program tries to determine how it has been called, by using argv, it will likely do the comparison case sensitive and might misunderstand the user. Try the program "whoami", for instance. Called like that, it presents a simple output - your username. Called like "whoamI", you get something else. In fact, "whoami" is just a hardlink to the program "id", which everytime tries to determine how it has been called and fails when the syntax "whoamI" is used.

Thanks to this link for the example above.

And FWIW, I think Apple is right to use a case insensitive filesystem. Use HFSX or UFS if you don't like it.

[jzdziarski]

It also doesn't help developers writing generic *nix applications, when everything works on osx but breaks on every other *nix because something isn't named right

[tooki]

Those developers can use one of the several case-sensitive filesystems at their disposal, then, as has been said here repeatedly. But for the average user, case insensitivity is VASTLY superior.

tooki

[leperkuhn]

i just fired up the old terminal, and typed LS, and i got a listing. this is pure BS. I just threw up all over my computer

Makes me clammor for the good old days of OS 6 when something like this could never have happened.

[Brass]

Originally posted by jzdziarski:
It also doesn't help developers writing generic *nix applications, when everything works on osx but breaks on every other *nix because something isn't named right

If any developer is dopey enough to do this, then it's their own problem. If they are writing generic unix apps, then they will know what case to write each character in.

In fact, even if they don't it's hard to get it wrong, as everything is is lower case for virtually everything in a case-sensitive unix/FS system.

[jasong]

Wow, I have been physically ill for the last 3 years. I never even put it together that it was OS X that was doing it to me. And for those of you naysayers, I booted into OS 9, and sure enough, I wasn't sick anymore.

I'm getting a lawsuit together . . .

-- Jason

[bmedina]

Somehow I don't think the jokes about being physically ill should be funny. Yet, each one makes me laugh.

[Gavin]

Building PHP on OS X used to be a problem because it had a file called pear and a folder called PEAR in the same directory.

PHP changed it. No big deal.

Case sensitivity came about not because anybody particularly wanted it that way but because case insensitivity was too hard to do. Back in the Olden Days the amount of horse power it takes to compare ascii a to ascii A actually made a difference. Especially if you're only allotted 45 minutes of run time a week on the main frame and the university won't spring for the fancy card punch with the shift key.

[jzdziarski]

I think it's where the case insensitivity originally came from that makes me want to blow lung butter all over the keyboard. Case insensitivity is synonymous with DOS, and personally I consider it to be a limitation or even a weakness in a filesystem. It might not hurt most mac users, but it smells very foul - foul enough to raise my bile to the back of my throat. It's like saying, lets build an amazing operating system with the most secure and stable kernel in the world (BSD), and then lets ruin the filesystem by giving it DOS-like qualities.

Can most people suffer through it? sure... but it still smells and feels a lot like DOS, or dos.

[Chuckit]

Case insensitivity is synonymous with DOS? I don't see how that works. It was a feature of the original Mac OS, which was specifically designed not to inherit DOS's weaknesses (to the extent that Apple chose not to give it a command line). You may as well say (like some old-school Mac users have) that Bash smells like DOS because it allows you to type in commands. DOS was case insensitive, and it did allow you to type in commands. If you want to get away from DOS, avoid Unix at all costs!


In summary: Case sensitivity is a confusing misfeature. Whether or not one poor operating system happened to include this misfeature, case insensitivity is a much more logical paradigm that Apple carefully decided matches the way people think.

[leperkuhn]

Originally posted by Chuckit:

In summary: Case sensitivity is a confusing misfeature. Whether or not one poor operating system happened to include this misfeature, case insensitivity is a much more logical paradigm that Apple carefully decided matches the way people think.

We've also seen a decline in carpel tunnel. That however, is offset by increased vomiting, diarreah, and in rare cases lycanthropy

[Severed Hand of Skywalker]

Is this like the worst thing that could happen to a nerd?

[Tsilou B.]

Originally posted by jzdziarski:
I think it's where the case insensitivity originally came from that makes me want to blow lung butter all over the keyboard. Case insensitivity is synonymous with DOS, and personally I consider it to be a limitation or even a weakness in a filesystem. It might not hurt most mac users, but it smells very foul - foul enough to raise my bile to the back of my throat. It's like saying, lets build an amazing operating system with the most secure and stable kernel in the world (BSD), and then lets ruin the filesystem by giving it DOS-like qualities.

Can most people suffer through it? sure... but it still smells and feels a lot like DOS, or dos.

Sorry, but that's bullsh... Unlike the early DOS versions, HFS has always been case-preserving and most Mac users like it that way. As several people have already pointed out, it's a little bit more difficult to develop a case-insensitive file system than a case-sensitive one. And just because BSD uses some conventions and BSD is one of the most stable operating systems in the world doesn't mean that BSD does everything right.
E.g. I hate it when I open a file, think I should rename or move it, do that using the Finder, later save the file and the application creates a new file at the old location with the old name instead of using the file I moved and renamed. That's a "feature" some applications inherit from BSD and to plagiarize you, it smells very foul - foul enough to raise my bile to the back of my throat. It's like saying, lets build an amazing operating system with the most advanced user interface in the world (Mac OS), and then lets ruin the OS by giving it DOS/Windows-like qualities.

[Agent69]

I just enabled case sensitive HFS (HFSX) in Disk Utility as mentioned in this hint:

http://www.macosxhints.com/article.p...00502011939237


Then, I created a Mac OS X boot cd-rom using CharlesSoft's BootCD. (Since BootCD uses the system disk to create its bootable CD, it automatically kept the HFSX capability.) I then booted from the new boot CD, used Disk Utility to format the internal hard disk in HFSX, and then reinstalled Mac OS X from the install disks; taking care not to reformat the drive.

So there is a round about way to get a case sensitive HFS boot disk, if you desire it. You can also accomplish this easier if you have an alternate boot disk, like a firewire drive, or a

Hope this help you Jzdziarski.

[CharlesS]

Originally posted by tooki:
Again: most UNIX utilities actually work fine on the case-insensitive filesystem, and if you really need to, you can make it case-sensitive! So what is all the fuss about?!?

Well, you see, I have this friend named Rm -Rf. If I were writing a letter to him, and accidentally did it in Terminal instead of Word, who knows what could happen? And it would all be because of case insensitivity in the file system. and if you can't tell it's a joke, you're a retard

[Gavin]

I love your stealth disclaimer! ;-)



Now as to zjd.. comparing a unix shell with DOS, that's hitting below the belt. Pure evil, man!

[Gavin]

DP

[Detrius]

Originally posted by Zarafa:
By the contents. Or size. Or position in the filesystem.{Detrius: You know, position already works. You can have two files of the same name in different folders.} Or author. Or creation date. Or last-modified date. Or any one of many other attributes. This is much the same way that, for instance, you can distinguish between multiple emails of the same title, or multiple songs with the same or similar titles.

I grant that these methods of discovery are not [yet] exposed through the Finder, shell commands, or other methods adequately. Certainly email messages and music files are much easier to distinguish in their respective applications than are "regular" files in the filesystem.

Using a file name is kind of a silly concept in the first place. There aren't a lot of other situations in the world where a name (by itself), or case, is the only piece of data used to identify an object [e.g. I share a name with someone in my company -- yet there is almost nothing, other than emplyer, that is similar about us otherwise, and people have confused us, even in email, no more than I've been confused with others who might share some similar roles, or have similar phyical characteristics as me].

Forcing an object to even have a name doesn't make too much sense, when you really think about it. I have notes throughout my [physical] filing system, on my desk, in my wallet, etc. that are all untitled. Yet the content, intent, author and other characteristics are readily apparent.

In a filesystem that acts like a database, names shouldn't have any special significance. There's no reason any number of files shouldn't be able to have the same name (or no name) within a given directory, especially as the concept of fixed directories slowly loses relevance. Within "Smart Folders" (iTunes, Tiger, etc.) it's certainly possible to have files that share names [including case].

It is certainly true that "behind the scenes", computers will have to track each file by some sort of unique identifier. That's OK, they're good at that sort of thing; do you worry about the session ID of each of your TCP transactions, for instance? But within the normal user-exposed view of files, names shouldn't impose the constraints that they do now.

I will leave some of the usability issues -- how to best expose metadata to visual or other inspection in a readily-apparent manner -- to the experts , though I submit that iTunes, any good email application, and similar apps for other types of media have already started down the path of solving these sorts of things.

You make a lot of really good points. The problem is that they don't support an argument that file systems should be case sensitive. Yes, there are a lot of different ways that we COULD figure out which file we need. However, even if there were a more efficient method of looking at all of the metadata, none of these methods would be more efficient than naming files "Readme for build info" and "Readme for installation info." Why would you force someone to look at extra information?

Also, you bring up the point of databases. There must be a primary key. Each file in HFS has its own unique descriptor. This is the primary key--it's how aliases work the way they do. This unique descriptor is just some effectively random binary number. One thing you must remember about databases is that they work better when they are simpler. You are supposed to normalize the database. Why make a primary key that is made up of six fields when it only has to have one field? The point of the file system and directory structure is to make it possible for humans to find files.

You brought up the point of a person in the company with the same name as you. Obviously that does not make you two the same person. Obviously, similar names confuse people. People rely on names. That's what language is. Every word is a name for an idea, action, object, etc... 'Chair' does not define a different object from 'chair.' So there are two Bobs... One is the Bob that's on the third floor in the corner office, and the other is the Bob that's on the fourth floor in the second office on the left. There's also a third Bob that's on the third floor in the second office on the left. Note though that if I talk about Bob on the fourth floor second office on the left, but you talk about Robert on the fourth floor, second office on the left, we are not talking about two different people. I don't need to verify birthdate, height, weight, number of children, etc... because I already have enough information. Even if you thought the weight was different, it wouldn't change who we are talking about. There is a more obvious and better organized method of telling the difference between two different objects. In this case sensitivity discussion, Robert and Bob are the same, like README and readme are the same. The fact that Bob's ID card says Robert does not make him not Bob.

As far as your iTunes example goes: You have a directory structure: at the bottom is the artist. Next is the album. Then the track number. The track name can also be substituted here at this level. Are you sure you want Aerosmith and aerosmith to be two different entries?

With your example of a nameless file in a filesystem. How do you expect to find that file? What if it were a photograph of your trip to the beach? How would you find it? If there is no name, you would have to know the precise time and date the picture was taken to find the photograph. Oh, you could put a description inside the photo saying it's a photo of your trip to the beach. But wait, you just effectively named the file! How would you distinguish between 1000 pictures you took on that beach trip? Suppose you want the ones where you went to the bar. You could leave them nameless, but put the metadata in. Well, you effectively just gave the photo a name. Are you sure you want 'bar' to be different from 'Bar' in that metadata? Why would you want that to be case sensitive?

Lastly, case sensitive file systems came about because of lazy programmers--not because anyone ever thought that it was a good idea. The computer stores a different stream of bits for 'A' than it does for 'a.' These lazy programmers simply compared the bit streams. If they weren't identical, there was no match. This is the way ASCII works.

Would you prefer google to be case sensitive? How many different searches would you have to do to find the information you want? I can tell you that you would have to do three to be reasonable.


There is no reasonable argument for humans to want a case sensitive file system. You can't come up with a easier, more logical method of describing files than to put a descriptive name on them. That's why OS X gives you 256 characters, instead of the 32 characters of OS 9, or the 8 characters of DOS. More characters means a better description.