Mac OSX Command-Line is Partially Case Insensitive
I've recently noticed a behavior in the command-line in Mac OS X. This environment, like all *NIX environments, is case sensitive. Typing:
cd /Library
is different from typing:
cd /library
To UNIX, /Library and /library are different directories.
However, I've found that in Mac OS X, typing either of those commands will put me in the same directory. Mac's brand of UNIX seems to be case-insensitive. Weird.
Actually, this has to do with the filesystem, rather than UNIX. Mac's default filesystem is HFS+(Journaled), which is not a case-sensitive filesystem. So the Mac command-line behavior honors this since, on the filesystem, which is at a lower level than the command line, there is no difference between /Library and /library. The command-line environment will, however, mimic case-sensitivity on HFS+ filesystems to a certain degree. For instance, tab-completion of file paths is case sensitive. But typing full file paths seems to default to the case sensitivity of the active filesystem. In fact, if I ssh to a UNIX box or an NFS mount on a UFS or ext3, or other case-sensitive volume, things work as expected in the *NIX world.
cd /Library
is different from typing:
cd /library
To UNIX, /Library and /library are different directories.
However, I've found that in Mac OS X, typing either of those commands will put me in the same directory. Mac's brand of UNIX seems to be case-insensitive. Weird.
Actually, this has to do with the filesystem, rather than UNIX. Mac's default filesystem is HFS+(Journaled), which is not a case-sensitive filesystem. So the Mac command-line behavior honors this since, on the filesystem, which is at a lower level than the command line, there is no difference between /Library and /library. The command-line environment will, however, mimic case-sensitivity on HFS+ filesystems to a certain degree. For instance, tab-completion of file paths is case sensitive. But typing full file paths seems to default to the case sensitivity of the active filesystem. In fact, if I ssh to a UNIX box or an NFS mount on a UFS or ext3, or other case-sensitive volume, things work as expected in the *NIX world.
btw, typing
cd ; echo 'set completion-ignore-case on' > .inputrc
will make completion case insensitive, which saves some time instead of pressing those Shift buttons :).
6:03 PM
Thanks. I did not know that.
-systemsboy
8:47 AM
But typing full file paths seems to default to the case sensitivity of the active filesystem. In fact, if I ssh to a UNIX box or an NFS mount on a UFS or ext3, or other case-sensitive volume, things work as expected in the *NIX world.
Surely that's because after you've sshed to the remote machine the commands are running on that remote machine, not on your own?
11:22 AM
Yes, that's what I'm saying. The actual case-sensitivity is dependent on the volume on which you are issuing commands: On an HFS+ volume, which is not case-sensitive, you can use commands without case-sensitivity. But as soon as you move to a volume that IS case-sensitive (via ssh, or simply by cd-ing to one), the command-line environment becomes case-sensitive.
This is weird and confusing, and I think it's why Apple seens to be moving toward—or at least offering the option to use—a case-sensitive version of HFS+:
Article 1
Article 2
-systemsboy
3:19 PM
Re: first comment
To append the line to the .inputrc file instead of overwriting it I'd suggest using:
echo 'set completion-ignore-case on' >> ~/.inputrc
Check the "Appending Redirected Output" section of the bash man page for more info.
» Post a Comment