Are bash commands on OSX case insensitive? I type "which TR" and it shows /usr/bin/TR, though there is no such binary there. Same thing for other binaries, when capitalized. Or is Terminal.app maybe doing this translation? How do I turn this off?

  • Out of curiosity, why would you want to turn this off? Aug 17 '11 at 16:04
  • This is a spectacular question. Bash has a nocaseglob option to control whether cases match in ranges, but this little bit of trickery is deeper than the normal locale and completion-ignore-case / nocaseglob
    – bmike
    Aug 17 '11 at 16:11
  • 4
    The reason I wanted to turn it off is silly, really. I'm used to case sensitivity when working at the shell. I am just worried this feature will trip me up. Example, I write a bash script, mistype 'lS'; the script will run fine on OSX. I move it to my cenTOS box, and it breaks. Granted, this would be easy to detect and fix, but could avoid the scenario entirely if I could keep the scripts working the same way between the two systems. I discovered this by accident, and it hasn't been a nuisance thus far, so I probably will not go through the exercise changing filesystems just for this.
    – verboze
    Aug 19 '11 at 1:30
  • 6
    The reason you would want to turn this off is that case insensitivity causes problems for some apps, like SVN. Case insensitive globbing could be useful, but SVN gets very very confused if you create a file called "Foo", then somehow the repository creates a reference to "foo".
    – user41214
    Feb 5 '13 at 19:01
  • 2
    Another reason to disable: I have had a script ~/bin/CC in my path since circa 1980. cc plus some pleasant defaults. It has worked from UNIX v6 through v7, Eunice, BSD 4.1, 4.2, 4.3, SVr4, Xenix, Gould UTX, Linux, cygwin... and it failed for the first time on MacOS, infinite recursion.
    – Krazy Glew
    Oct 9 '15 at 2:24

This is actually a feature of the filesystem of your disk, not bash or Terminal.app.

HFS+ (the Mac filesystem) is usually configured to be case insensitive but case preserving. This means that the file system will consider foo and FoO to be the same, but when you create a new file it will remember which letters where capitalized and which were not.

When you format a disk with HFS+ you can chose whether the file system should case sensitive or not. If you chose to format with UFS (Unix FileSystem) it is always case sensitive, AFAIK.

To check whether a disk is case sensitive, run:

 diskutil info <device>

For example:

 diskutil info disk0s2

Look for the Name: line. If it reads something like Mac OS Extended (Case-sensitive, Journaled) it means that it is case-sensitive. If it just reads Mac OS Extended (without the Case-sensitive) then it is only case preserving but not case sensitive.

  • 7
    Outside of Unix, the case preserving nature isn't so unusual. For example, NTFS is the similar: not case sensitive by default, but you can format it so it is. I also think that the case insensitive is default came via Mac OS 9, but the fact that a lot of Mac and Windows developers are lazy in this respect and don't care about correct casing makes it almost impossible to switch to case sensitive as default, it breaks lots of apps. Coming from Unix, I found it very strange at first as well.
    – DarkDust
    Aug 17 '11 at 16:57
  • 1
    I have to admit I never used Classic Mac OS, so was guessing. Either way, this is the answer, and DarkDust put it better than me so this one should be accepted I think.
    – stuffe
    Aug 17 '11 at 17:11
  • 6
    Every version of Mac OS has been case-insensitive-but-preserving, for usability reasons. While UNIX favours precision (byte-by-byte comparisons of filenames), it can be a usability nightmare for end users who accidentally save 'Resume' and 'REsume' and then get confused when they open the wrong version and all their changes are gone.
    – Dan Udey
    Aug 17 '11 at 17:30
  • 2
    On the other hand, it can also be a "usability nightmare" when typing "HEAD" at the command-line results in the program /usr/bin/head (show first lines of a file) being executed instead of /usr/local/bin/HEAD (from LWP: make an HTTP 'HEAD' request).
    – TML
    Apr 23 '13 at 17:12
  • 4
    Thinking that for every uppercase character there is one lowercase equivalent and vice versa is typical of English speaking programmers, and is not locale-independent. I don't know what solution has been adopted for Turkish, where there is the dotted lowercase i corresponding to the DOTTED uppercase İ, while the dotless uppercase I corresponds to the DOTLESS lowercase ı, but ANY solution will be bad. And what about the German ß, often capitalized with 2 Ss? And accents that are often left out when capitalizing? And... Case sensitivity does away with all of these headaches. Jun 19 '15 at 16:42

I managed to fix this with one line by following http://blog.nickburwell.com/blog/2008/11/mac-os-x-terminal-case-insensitive-auto

echo "set completion-ignore-case On" >> ~/.inputrc
  • This appears to be the only answer that answers the "how can I turn this off" portion of the OP. Dec 15 '19 at 0:39

Take a look at your filesystem, as there are both case sensitive and case insensitive variations on HFS. The default is case insensitive, in which case it's not so much a case of BASH, but the underlying filesystem. You can test this by formatting a spare USB stick with the case sensitive option, and copying files over ato repeat your test, etc.


It's your file system thing.

I'm using APFS, it's also case insensitive but case-preserving. This post provides a good explanation about H(ierarchical)FS and APFS.

#include <sys/stat.h>
#include <iostream>
int main(int argc, char **argv) {
    struct stat sb;
    int ret = stat(argv[0], &sb);
    std::cout << ret << std::endl;

output of this program using stat:

$ ./a.out ./test_dir/cat.png
$ ./a.out ./test_dir/caT.png

a simple bash test

$ cp cat.png caT.png
cp: caT.png and cat.png are identical (not copied).

As for bash, I believe it's also case insensitive on Mac OS if you are using the default HFS or APFS since command executable is also a file and when you type a command name, the name is used search through search PATH to find that file to be executed.

$ echo x X
x X
$ eChO x X
x X


Bash is definitely case sensitive.

I just typed whoami into terminal and the caps lock button was on.

I got a completely different response from WHOAMI.

I can see there is a WHOAMI command with which but I can't find it with ls.

  • 5
    This isn't the shell being case sensitive, it's the whoami program itself. It's actually the same program as id, but it checks which name it was run as, and uses a different output (equivalent to id -un) if run under the name "whoami". That check is case sensitive. Compare the output of id, WHOAMI,WhOaMi, WhoAmI, etc. Also, compare the output of ls -li /usr/bin/whoami vs ls -li /usr/bin/WHOAMI, and note that the inode number (the first thing listed in the output) is the same -- they're two different ways of specifying the exact same file. Apr 21 '17 at 16:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .