file names not case-sensitive?

[ghanwani]

Every unix system that I've worked with has had case-sensitive
file names. In other words, file name "foo" is different than
"Foo" is different than "FOO" and so on. In the MAC OS X shell,
if I have a file name FOO, and I type "more foo", then the
contents of FOO are displayed, instead of an error message
saying "foo not found". It also means that I can't really create
files "foo" and "FOO".

Is this something that Apple has implemented on top of unix?
Is it possible to get around this, so that the names do indeed
become case-sensitive? It doesn't seem like an inherent unix
thing, because if I type "f <tab>", and the only file in the directory
is FOO, it doesn't complete.

Thanks,
Anoop

 

[skunk]

I have found this irritating, too. It would often be nice to be able to have a folder name in caps and a file inside in lower case with the same name.

 

[robbieduncan]

You misunderstand where the case sensitivity of "normal" Unix comes from. It's not from the Unix layer: it's from the filesystem. OSX runs on HFS+. No other Unix does. So that's the difference.

HFS+ is, by default, not case sensitive but is case preserving. You can re-fromat HFS+ as HFSX (case sensitive HFS+).

 

[skunk]

You can re-format HFS+ as HFSX (case sensitive HFS+).

Does that have any unexpected consequences for Mac users?

 

[spinnerlys]

It may have to do with the file system, as one can choose "Mac OS Extended (Case-sensitive)" as file system to format any HDD.

Ahh, screenshots get you downer. Bollocks.

 

[robbieduncan]

Does that have any unexpected consequences for Mac users?

Badly written software could, potentially, not work as expected. If the programmer, for example, uses a file called mainmenu.nib as their root nib file but actually called the file MainMenu.nib then the app would work on HFS+ and fail to start on HFSX.

 

[ghanwani]

You can re-fromat HFS+ as HFSX (case sensitive HFS+).

Thanks.

Apple should offer this as an option at the time of purchase...not really looking forward to erasing and doing a full install. Any idea how long a full install takes?

Anoop

 

[robbieduncan]

Thanks.

Apple should offer this as an option at the time of purchase...not really looking forward to erasing and doing a full install. Any idea how long a full install takes?

Anoop

Depends on how much data you have to restore, third party apps to reinstall at so on. A few hours at least. As noted above there may be consequences. If you have a spare external drive I'd recommend trying the install on that and ensuring all your critical software still works.

 

[skunk]

Badly written software could, potentially, not work as expected. If the programmer, for example, uses a file called mainmenu.nib as their root nib file but actually called the file MainMenu.nib then the app would work on HFS+ and fail to start on HFSX.

Just for that, I think I'll stick with the irritation.

 

[ghanwani]

Depends on how much data you have to restore, third party apps to reinstall at so on. A few hours at least. As noted above there may be consequences. If you have a spare external drive I'd recommend trying the install on that and ensuring all your critical software still works.

So far, just the base system with Chrome and KompoZer. I think I'm going to just live with it for now. But it's good to know that I have the option of getting case-sensitive file names if I develop a craving for it down the line.

Thanks,
Anoop

 

[FourCandles]

...You can re-fromat HFS+ as HFSX (case sensitive HFS+).

Does that have any unexpected consequences for Mac users?

For an example, Adobe Creative Suite won't install on a volume using a case-sensitive file system.

Oh, wait... :

Badly written software could, potentially, not work as expected. ...

Already been covered

 

[Sydde]

I have found this irritating, too. It would often be nice to be able to have a folder name in caps and a file inside in lower case with the same name.

"inside"? How would a folder name constrain the name of a file inside it? Am I misunderstanding something?

 

[Gregg2]

I have found this irritating, too. It would often be nice to be able to have a folder name in caps and a file inside in lower case with the same name.

"inside"? How would a folder name constrain the name of a file inside it? Am I misunderstanding something?

You beat me to it!

 

[Hal Itosis]

It doesn't seem like an inherent unix thing, because if I type "f <tab>", and the only file in the directory is FOO, it doesn't complete.

If pathname completion on the command line is the main source of your aggravation here, then just put this line in your ~/.bashrc file:

bind 'set completion-ignore-case on'

 

[ghanwani]

If pathname completion on the command line is the main source of your aggravation here, then just put this line in your ~/.bashrc file:

bind 'set completion-ignore-case on'

That wasn't my main concern, but this is definitely a useful piece of information.

I've been putting my customizations in .bash_profile, rather than .bashrc...that would work too, right?

 

[Hal Itosis]

That wasn't my main concern, but this is definitely a useful piece of information.

I've been putting my customizations in .bash_profile, rather than .bashrc...that would work too, right?

Yeah but, only for login shells then.

So ~/.bashrc is better. E.g., if we spawn a root shell via sudo -s, then the feature will be there too. [technically, we should put "set completion-ignore-case on" in a ~/.inputrc file, so that other shells besides bash (like tcsh) could read it as well... but i just use bash, so ~/.bashrc is the place for me.]

 

[ghanwani]

Yeah but, only for login shells then.

So ~/.bashrc is better. E.g., if we spawn a root shell via sudo -s, then the feature will be there too. [technically, we should put "set completion-ignore-case on" in a ~/.inputrc file, so that other shells besides bash (like tcsh) could read it as well... but i just use bash, so ~/.bashrc is the place for me.]

I was under the impression that .bashrc doesn't get executed on MAC OS X terminals, unless you have something in your .bash_profile to run it.
http://www.joshstaiger.org/archives/2005/07/bash_profile_vs.html

Based on what you say, it looks like both are executed for Terminal windows?

 

[Hal Itosis]

I was under the impression that .bashrc doesn't get executed on MAC OS X terminals, unless you have something in your .bash_profile to run it.

Well, it depends on which startup files exist inside a user's home. If bash finds a ~/.bash_profile file, it will [automatically] source that one. If not found, then bash looks for ~/.bash_login (and then ~/.profile i think). If none of those exist, i think it might go for ~/.bashrc (but i haven't checked).

But anyway, you've hit upon the method which i (and most others) employ: use *both* ~/.bash_profile and ~/.bashrc... and then have a line such as this in ~/.bash_profile:

. ~/.bashrc || echo "problem sourcing ~/.bashrc"

My initial point wasn't about choosing to use only one or the other... but rather, in which of them should we put our environmental tweaks (shells options, readline bindings, aliases, functions, etc).

Based on what you say, it looks like both are executed for Terminal windows?

I wasn't talking about window behavior per se, but rather: what happens (or doesn't happen) when one spawns an interactive subshell, within an already existing login window.

As i indicated earlier, this is very noticeable when we spawn a root shell via

sudo -s

...because none of the stuff in ~/.bash_profile goes along for the ride.

I use ~/.bash_profile mostly for login nonsense...

UpString=$(uptime |sed 's/^.*up *//;s/, *[0-9]* user.*$/m/;
s/ day[^0-9]*/d, /;s/ \([hm]\).*m$/\1/;s/:/h, /;s/ 0/ /')
printf '\n\e[1mMachine: %s\nUp-time: %s\e[0m\n' "$MACHTYPE" "$UpString"
echo
finger `whoami`
echo
cal|sed "s/^/ /;s/$/ /;s/ \($(date +%e)\) / $(printf '\e[1m\\1\e[0m') /"
echo
grep -h "^`date +%m/%d`" \
/usr/share/calendar/calendar.{birthday,computer,history,holiday,music} |
sed 's@^[^[:alpha:]]*@@'
echo

... and then source ~/.bashrc from there (as previously shown), because that's where the beef is.