[va3uxb]

I'm using 10.3.3, my shell is bash, and I'm accustomed to case sensitive systems.

Is there any way to either make OS X become case sensitive, or at least, trick it into acting case sensitive?

Like when I'm in my ~ directory and I type "cd documents" I'd rather it tell me the directory doesn't exist than put me into ~/Documents

I don't actually need to be able to have a "Documents" and "documents" directory or file, I'm not planning on saving files where I need that capability. I just prefer it to be strict, so that I don't get lazy about it and inadvertantly mess something up on another unix / linux system.

Is there any way to achieve this?

Thanks!

[utidjian]

Originally posted by va3uxb:
I'm using 10.3.3, my shell is bash, and I'm accustomed to case sensitive systems.

Is there any way to either make OS X become case sensitive, or at least, trick it into acting case sensitive?

Like when I'm in my ~ directory and I type "cd documents" I'd rather it tell me the directory doesn't exist than put me into ~/Documents

I don't actually need to be able to have a "Documents" and "documents" directory or file, I'm not planning on saving files where I need that capability. I just prefer it to be strict, so that I don't get lazy about it and inadvertantly mess something up on another unix / linux system.

Is there any way to achieve this?

No. The problem with Documents/documents is the filesystem NOT the shell. The filesystem is "case preserving" but NOT "case sensitive". Some would argue that this makes sense... some would not... some would just argue. Because of this it would be very hard to make a shell that behaves "correctly".

[va3uxb]

Ah... and the filesystem is the HFS that is selected when formatting the hard drive?

Hmm, so if I reformatted it all as a Unix volume then re-installed Panther, would I get proper case sensitivity? Or would I get a big crash and a system that didn't work any more?

Thanks for the help!

[JNI]

Originally posted by utidjian:
No. The problem with Documents/documents is the filesystem NOT the shell. The filesystem is "case preserving" but NOT "case sensitive". Some would argue that this makes sense... some would not... some would just argue. Because of this it would be very hard to make a shell that behaves "correctly".

This is not entirely true. The shell can be set either way, and the filesystem can be set either way. And then there are some interaction issues between the two. It depends on what commands you are executing as far as how it all reacts. E.g. when you set the shell to be case-[in]sensitive, it mostly means for things like command completion and argument expansion. But when you use a command that writes through to the filesystem, then the filesystem itself can react with some case [in]sensitive behavior.

When you format the hard drive, at least in Panther, you can choose HFS+ or HFSX, where HFSX is fully case sensitive. You DON"T want to format to the Unix file system, as that doesn't support a bunch of stuff needed for proper Mac operation, like resource forks, meta-data etc. The only time you would want to format to a raw Unix file system is if you are running all non-Mac applications, like running raw Darwin for some kind of server operation or are using some window Manager other than Aqua.

What it sounds like the original poster needs to do is format the drive as HFSX, and then set his shell to be case sensitive too. That is the only way you will get a fully case sensitive system.

[ChrisF]

Originally posted by JNI:
What it sounds like the original poster needs to do is format the drive as HFSX, and then set his shell to be case sensitive too. That is the only way you will get a fully case sensitive system.

Case-sensitivity is not recommended by Apple for boot disks.
Chris

[Moonray]

Originally posted by va3uxb:
Ah... and the filesystem is the HFS that is selected when formatting the hard drive?

Hmm, so if I reformatted it all as a Unix volume then re-installed Panther, would I get proper case sensitivity? Or would I get a big crash and a system that didn't work any more?

Thanks for the help!

You would get case-sensitivity, but UFS does not store some file metadata HFS does. So applications that rely on them would get into trouble.

-

[va3uxb]

and then set his shell to be case sensitive too.

I'll settle for it working partially. How do I set the shell to be case sensitive? I'm using bash.

Thanks again!

[Arkham_c]

On OSX Server 10.3 you can format a drive as case-sensitive HFS+. I'm not sure if there's a way to do it in regular OSX though.

[JNI]

Originally posted by va3uxb:
I'll settle for it working partially. How do I set the shell to be case sensitive? I'm using bash.

Thanks again!

see man bash and search for 'sensitive'. There are a couple of different options you can set:

completion-ignore-case
nocaseglob

[JNI]

Originally posted by ChrisF:
Case-sensitivity is not recommended by Apple for boot disks.
Chris

I'm not saying I don't believe you, but can you post a reference that states this?

I don't see any mention of that in this tech note:
http://developer.apple.com/technotes...1150.html#HFSX

I noticed that they are up to HFSX version 5 with Panther. Maybe your info is old?

I imagine that there could be issues, and Apple is probably waiting a while for any lingering case-insensitive scripts and such to get flushed from the installed base. Maybe it will be safer after it's been in the field for a while and more broadly tested.

[ChrisF]

Originally posted by JNI:
I'm not saying I don't believe you, but can you post a reference that states this?

I don't see any mention of that in this tech note:
http://developer.apple.com/technotes...1150.html#HFSX

I noticed that they are up to HFSX version 5 with Panther. Maybe your info is old?

Note that HFS+ with case sensitivity is only an option with OS X Server.
Here you go.
The installer won't even allow the installation to proceed on an HFS Case-sensitive disk.
Chris

[OreoCookie]

Ditto, HFS on Magnum allows case-sensitivity. Every shell is case-sensitive in the sense that if you have the file bla.text, then rm Bla.text will not delete bla.text.

[utidjian]

Originally posted by JNI:
This is not entirely true. The shell can be set either way, and the filesystem can be set either way. And then there are some interaction issues between the two. It depends on what commands you are executing as far as how it all reacts. E.g. when you set the shell to be case-[in]sensitive, it mostly means for things like command completion and argument expansion. But when you use a command that writes through to the filesystem, then the filesystem itself can react with some case [in]sensitive behavior.

When you format the hard drive, at least in Panther, you can choose HFS+ or HFSX, where HFSX is fully case sensitive. You DON"T want to format to the Unix file system, as that doesn't support a bunch of stuff needed for proper Mac operation, like resource forks, meta-data etc. The only time you would want to format to a raw Unix file system is if you are running all non-Mac applications, like running raw Darwin for some kind of server operation or are using some window Manager other than Aqua.

Checking Disk Utility... I get three choices of filesystem: Mac OS Extended (Journaled), Mac OS Extended, and UFS. As I understand it Mac OS Extended is the "new" HFS+. System Profiler lists my disk(s) as HFS+ (I selected Mac OS Extended (Journaled) when I set them up). I have heard of the option called Mac OS Extended (Case-sensitive/Journaled) but I have never seen it in Disk Utility for Panther. There is small button in that window called Options... but it is always greyed out. No doubt UFS is fully case-sensitive. Perhaps my Panther is different from your Panther.

What it sounds like the original poster needs to do is format the drive as HFSX, and then set his shell to be case sensitive too. That is the only way you will get a fully case sensitive system.

The shell, by default, IS case sensitive... at least for filename completion:

Code:
core:~ utidjian$ cd /s[Tab][Tab]
sbin  sw
core:~ utidjian$ cd /S[Tab]ystem/

Which is the way it should be... BUT my Mac OS Extended (Journaled) filesystem is kinda screwy.

Code:
core:~ utidjian$ cd /system
core:/system utidjian$ pwd
/system
core:/system utidjian$

WTF? There is NO folder called "/system", there IS a folder called "/System".

Code:
core:/system utidjian$ cd /System
core:/System utidjian$ pwd
/System
core:/System utidjian$

I can imagine this plays hell with some shell scripts.

In any case I don't see how one can make Mac OS X behave the original poster wants it to in and of itself if one uses the Mac OS Extended (Journaled) filesystem. If he reformats the the disk as UFS then perhaps it will behave... but that can also lead to problems. I don't remember the specifics of why to avoid using a UFS filesystem.

I don't have the problem that the original poster has because my home folder is NFS mounted from a Linux server.. this effectively makes my ~/ folder and everything under it case sensitive.

[utidjian]

Originally posted by JNI:
see man bash and search for 'sensitive'. There are a couple of different options you can set:

completion-ignore-case
nocaseglob

Try em. It does not solve the problem.

[utidjian]

Originally posted by OreoCookie:
Ditto, HFS on Magnum allows case-sensitivity. Every shell is case-sensitive in the sense that if you have the file bla.text, then rm Bla.text will not delete bla.text.

Interesting. I haven't touched Magnum yet. That must be a provision for clients that might not be running Mac OS X (makes sense anyhow). So the solution for the OP might be to install Magnum and then he will have a case sensitive FS AND all the metadata goodness. I think once Classic is pretty much dead and gone Apple wil drop the entire HFS+ scheme altogether.

[rkt]

Originally posted by va3uxb:
Like when I'm in my ~ directory and I type "cd documents" I'd rather it tell me the directory doesn't exist than put me into ~/Documents

Is there any way to achieve this?

[wider:~] rkt% cd p<\t>
photos/ python/

[wider:~] rkt% cd P<\t>
Pictures/ Public/

it's sort of half possible... provide you use tab a lot :)

[tooki]

Originally posted by JNI:
I noticed that they are up to HFSX version 5 with Panther. Maybe your info is old?

The technote also mentions that the ONLY possible version value for HFSX is 5 -- earlier numbers were for HFS types other than HFSX.

tooki

[Agent69]

I know that UFS does not support resource forks but the only apps that really even deal with them anymore are Carbon/Classic apps, right? Does anyone even know of any Cocoa apps that use resource forks?

If you mainly just work in your home directory, I suppose that you could create a second, non-boot UFS partition and move your home directory onto it. Either that or figure out how to make your home directory live in a disk image like the way File Vault does.

[JNI]

Originally posted by Agent69:
I know that UFS does not support resource forks but the only apps that really even deal with them anymore are Carbon/Classic apps, right? Does anyone even know of any Cocoa apps that use resource forks?

If you mainly just work in your home directory, I suppose that you could create a second, non-boot UFS partition and move your home directory onto it. Either that or figure out how to make your home directory live in a disk image like the way File Vault does.

Carbon apps are still being used and even developed today, which means they could be creating files that use resource forks. So unless you are absolutely sure that you aren't going to ever use any Carbon apps, having your home directory on a UFS partition would likely be a problem.

I believe that Apple's recommendation is to only use UFS partitions with servers and such, where the tools are hard coded to read/write to a specific partition and are guaranteed to not need resource forks. For a client system where users may be manually moving around files, it seems like a bad idea.

[OreoCookie]

Would that be the reason why Apple is trying to "enhance" HFS further and further instead of choosing better alternatives (or make a better one themselves). How about FreeBSD's FFS with SoftUpdates and a database on top.

[JNI]

Originally posted by OreoCookie:
Would that be the reason why Apple is trying to "enhance" HFS further and further instead of choosing better alternatives (or make a better one themselves). How about FreeBSD's FFS with SoftUpdates and a database on top.

I think that compatibility with all possible Macintosh file types is probably very important to them. Even 5 years from now people might want to open up an older file with old tax records in it, or whatever. It seems that they have made many significant improvements with HFS, going to HFS+ and now HFSX. So unless there is some reason that they absolutely cannot add a required feature to the HFS family of filesystems, I don't see why they wouldn't keep using incrementally enhanced versions of it.

[OreoCookie]

Originally posted by JNI:
I think that compatibility with all possible Macintosh file types is probably very important to them. Even 5 years from now people might want to open up an older file with old tax records in it, or whatever. It seems that they have made many significant improvements with HFS, going to HFS+ and now HFSX. So unless there is some reason that they absolutely cannot add a required feature to the HFS family of filesystems, I don't see why they wouldn't keep using incrementally enhanced versions of it.

Well, that has nothing to do with the filesystem.
All Apple would need to do is keep support to read HFS. It can read FAT32 alright (and write), so it would be no problem to access old data. Beyond that, each time you upgrade your computer, you transfer your files one way or the other.

[JNI]

Originally posted by OreoCookie:
Well, that has nothing to do with the filesystem.
All Apple would need to do is keep support to read HFS. It can read FAT32 alright (and write), so it would be no problem to access old data. Beyond that, each time you upgrade your computer, you transfer your files one way or the other.

Huh? How does that have nothing to do with the filesystem? HFS and FAT are filesystems, aren't they? Any replacement would be a filesystem, right? Reading and writing a file implies a filesystem, no? I don't really get what you are saying.

Sure you could still read secondary HFS volumes even if you had your user partition formatted to something else. But what if you want to copy a dual fork file with HFS metadata to an non-HFS formatted volume? It better be one that somehow maintains both the forks and the metadata. Sure, you could use AppleSingle, AppleDouble, MacBinary or some other kludge, but that's never shown to be a good solution. Files get broken all the time using those things.

What's your point, exactly?

[OreoCookie]

Originally posted by JNI:
Huh? How does that have nothing to do with the filesystem? HFS and FAT are filesystems, aren't they? Any replacement would be a filesystem, right? Reading and writing a file implies a filesystem, no? I don't really get what you are saying.

Sure you could still read secondary HFS volumes even if you had your user partition formatted to something else. But what if you want to copy a dual fork file with HFS metadata to an non-HFS formatted volume? It better be one that somehow maintains both the forks and the metadata. Sure, you could use AppleSingle, AppleDouble, MacBinary or some other kludge, but that's never shown to be a good solution. Files get broken all the time using those things.

What's your point, exactly?

My point is that most files will work without resource fork. Those which have one can use it like under a UFS formatted MacOS X partition: the resource fork is put in a separate file.

Sticking to HFS just for that reason wouldn't be a very good idea. Just do a search on the A20 gate and find out why a P4 Extreme Edition still has it. Backwards compatibility to the extreme

In case of files, they depend on applications. So if you still use certain files, you need the application that comes with it. No application = file is useless. Apple has migrated to XML-based files (see Keynote, you could automatically create your presentations by shell scripts as a friend of mine suggested).

New applications don't seem to use resource forks anymore and I'm anxiously awaiting the replacement, something similar to the BFS. And I'm pretty sure Apple is working on it, because M$ is working on one.

[Agent69]

Originally posted by OreoCookie:
New applications don't seem to use resource forks anymore and I'm anxiously awaiting the replacement, something similar to the BFS. And I'm pretty sure Apple is working on it, because M$ is working on one.

I don't use Classic and the only carbon app I use, GraphicConverter, gives me the option to turn off resource forks. While a good idea, I have never liked resource forks because they are not standard and simply caused too many problems in a cross platform setting.

As for Apple creating a file system similar to BFS, Apple does now employ the guy who created BFS, so we might one day see something like it.

[OreoCookie]

Originally posted by Agent69:
I don't use Classic and the only carbon app I use, GraphicConverter, gives me the option to turn off resource forks. While a good idea, I have never liked resource forks because they are not standard and simply caused too many problems in a cross platform setting.

As for Apple creating a file system similar to BFS, Apple does now employ the guy who created BFS, so we might one day see something like it.

I heard about that.
I guess Apple might announce something based on that for a future release, but this is just an educated guess. Apple needs to have something as a reaction to the announced WinFS (NTFS + MS SQL) that is to be included with Longhorn.

AFAIK Cocoa apps don't use resource forks ... and Carbon is moving away from that, too.

[va3uxb]

Just revisiting an older thread... I was having a lot of trouble with my iBook and the Apple tech had me do an erase and reinstall of Panther. When we got to the step where you select Erase, and the choice between HFS or Unix file systems, I asked him what was the difference, if there was a downfall to picking Unix.

His answer was, the only difference is if you pick Unix, you -Cannot- run any Classic anything. I guess Classic just won't go.

So, I've reinstalled everything after formatting my iBook with the Unix file system and everything seems to work fine so far.

And best of all, I've got my case sensitive shell! Yipee!

-Stephanie