94

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?

8
  • 6
    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, 2011 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, 2013 at 19:01
  • 3
    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, 2015 at 2:24
  • 1
    This just screwed me over as well. A build and dev deployment that work fine on OSX break in test on Ubuntu because I mistyped one letter in my gulp script in lower case rather than upper-case. I'm not a fan of this feature because it forgives errors that, in all likelihood, your production system won't.
    – Bart Read
    Jun 22, 2016 at 14:31
  • 1
    This did trip me up because something that worked in the macOS terminal did not work for me when working on CentOS and I was staring at the code until I realized that the possibility existed for case insensitivity on Mac.
    – demongolem
    Sep 2, 2020 at 20:29

5 Answers 5

110

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.

9
  • 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, 2011 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, 2011 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, 2011 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, 2013 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, 2015 at 16:42
8

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
2
  • This appears to be the only answer that answers the "how can I turn this off" portion of the OP. Dec 15, 2019 at 0:39
  • Best answer, it worked for me. Jun 4 at 19:25
6

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.

2

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
0
$ ./a.out ./test_dir/caT.png
0

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

0
1

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.

1
  • 6
    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, 2017 at 16:57

You must log in to answer this question.

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